Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Melting Sky]

My understanding is that stockpiles are also one of the major sources of FPS problems since they are constantly searching for items to be stored inside them.

It seems like containers within stock piles hurt FPS as well perhaps due to the weird cancellation spam you get as dwarves drag dozens of containers around the fortress preventing other dwarves from properly pathing to them to drop off and retrieve items.

[smjjames]

Planning a fort in one z level may help FPS, but its at a cost of efficiency. Namely, it's faster and more efficient for a job to go 6 tiles to the stairs up a z level and to point b than it is to go 20 tiles.

The wiki has some good designs and layouts.

A fort along one z level can be made efficient, but it takes planning to centralize the industries.

[smjjames]

Regarding the hauling, you can minimize that by putting the stockpiles next to (or one z level below with connecting stairs) and centralizing linked industries close to each other.

I quantum stockpile most things in the current fort. The only things that I don't quantum stockpile are cloth because you can fit so many of them in bins, plus the cloth stockpile is right below the clothier shops with very quick access, gems since they actually use bins efficiently with those, weapons, armor, and finished goods. I also put buildings in industry chains like clothes and soap making close to each other whenever possible and quantum stockpiling helps with making industry chains compact.

I should upload my fort to DFMA to show you the fort layout with stockpiles, that might help you get an idea of how to minimize hauling.

[pumpedupjellos]

I currently have a population count of 188, and am running the game on a liquid cooled Alienware system with a GTX 760 Graphics card... so I might just be able to give you the insight you're looking for 

Despite the relatively high population count, my fps generally stayed in the range of 40-60 depending on the number of idlers... that is until my dwarves opened up several serpent man, rodent man and amphibian man fortresses... and I tasked them with reclaiming all the items strewn about the underground fortresses.... then my framerate dropped to 6 FPS XD

In general, I surmise that population size don't adversely affect framerate as much as pathing calculations do and that pathing across z-levels uses much more processing power than across x and y levels. If you don't want an fps death, try not to unnecessarily open up new caverns and if you do accidentally open these caverns up, try to restrict access to said caverns.

[Bo-Rufus CMVII]

Sometimes my games slow to a crawl early on (~20 pop), then after a long while suddenly snap out of it and speed up again.

[Di]

While number of dwarves and their pathing does impact fps it's hardly the only one source of slowdown.
Recently I've run 30 dwarf fort for 30 years and fps went down from 140 to 15 simply with time passing.
The difference between 'all are hauling' and 'all are idling' is something around 10 frames, the big and open spaces never caused immediate slowdown (though I had rather small patches of land in my underground lake, so that might have cut the pathing done by critters there).
Then there's crap I've had several thousand of items on stockpiles, later on all crushed, which while seemingly slowing down the slowdown didn't change the ultimate results.
I've also had kid go insane while hauling bones for planepacked artefact if anyone is interested.

Pretty much anything that happens in df slows it down.
So, on i7 I wouldn't worry about number of dwarves but your fort is doomed anyway.

[TruePikachu]

In case it isn't really clear to some people, (as I understand it), big, empty areas don't contribute lag themselves, but rather trying to path to something next to one is likely the greater issue.

Assuming the game uses A* (I can't confirm), and assuming a 2-dimensional layout (there are very similar issues in 3D), pathing from point A to point B with no obstacles in the way (like in a big empty area) results in checking just the cells between point A and B. Pathing from an open area to a closed area, however, can cause a bottleneck. One can experiment with http://qiao.github.io/PathFinding.js/visual/

I ran a series of tests in it (not posting pics, sorry) with the node cost being 5 (what DF has it as by default):
* Test A - no walls in open area - path length 10, 47 operations
* Test B - one wall in open area - path length 13.31, 88 operations
* Test C - pathing from an open area into a "fort" with the enterance in the direction of the destination - path length 52.38, 401 operations
* Test D - reverse direction of C (path from "fort" to open area) - path length 52.38, 133 operations
* Test E - pathing from an open area into a "fort" with the enterance in the opposite direction of destination - path length 69.21, 1663 operations (in testing, the pathfinder actually started checking not only the back side of the "fort", but also tiles somewhat far from it)
* Test F - reverse of E - path length 69.21, 171 operations

The "fort" I was using was a unicursal maze (where there is only one path, and no branching). Actual forts will have more checks, and might be a bit harder to escape from.


In an (untested) analyses, the difference between a fort and an open space is that there are some tiles in a fort which one can't path onto. The main issue with pathfinding is the number and size of obstacles in the way; I should note that some fort designs have a big open space look like a potential way from one point to another, when it doesn't actually connect. I personally bury everything, so it is rare that the surface gets considered.

[WanderingKid]

I know Toady has stated (somewhere) that he uses a modified A*. 

If I had to guess, and this is an OUTRIGHT guess, the reason that different Z level targets would hurt pathing is because the pathfinder has to spread out on each floor between the two looking for the best path and for z-elevators (ramps, stairs, whatever).   Add to that dead end spiderwebs, etc... and I could see why that could occur.

However, I know that sealing off large mined areas from access will help in FPS.  I personally try to make sure I can just door up the mass dig, but sometimes I have to simply wall in the stairway and stick a door there (for later access, if absolutely necessary).  However, exposed tiles in general can cause a signficiant FPS loss.

As for stockpiles, that's one of the reasons QSPs help.  Another is, if I remember correctly, the 'get nearest item' bit for a dwarf, in the case of using stone or logs or whatever.  But, yeah, I don't know the code so bring your salt and a good bit of cynicism before you take me at face value on all this about the pathfinding intricacies.

[Hetairos]

I have a fort with 200 dwarves and when about 80 of them idle, the framerate is circa 13 FPS. However, after issuing a large number of jobs and leaving only about 20 idlers, it drops to ~9 FPS. Pathing does seem to be the source of the framerate drain here.

[Melting Sky]

Thanks for all the responses. It's been illuminating.

While number of dwarves and their pathing does impact fps it's hardly the only one source of slowdown.
Recently I've run 30 dwarf fort for 30 years and fps went down from 140 to 15 simply with time passing.
The difference between 'all are hauling' and 'all are idling' is something around 10 frames, the big and open spaces never caused immediate slowdown (though I had rather small patches of land in my underground lake, so that might have cut the pathing done by critters there).
Then there's crap I've had several thousand of items on stockpiles, later on all crushed, which while seemingly slowing down the slowdown didn't change the ultimate results.
I've also had kid go insane while hauling bones for planepacked artefact if anyone is interested.

Pretty much anything that happens in df slows it down.
So, on i7 I wouldn't worry about number of dwarves but your fort is doomed anyway.

One thing that is sad is that it seems no matter how efficiently you build your fortress and how few Dwarves you have living there, time will eventually bring your fortress's fps to its knees. This example you provided is very sobering. I pretty much figured a 30 dwarf fort could run for all eternity without a slow down but apparently even this tiny number of dwarves can survive for only so long.

[Zammer990]

I build horribly inefficient fortresses and my current one has ~110 dwarves, getting 20-30 fps when most are idling, when all are hauling, drops to 10. I'm using fastdwarf DFhack to mediate the slow movement

[timotheos]

The other things that kills FPS is lots of designated jobs. My killer is when i designate my fort for smoothing. I can go from 25fps to 5fps if i designate too much at a time. Even small areas can make a noticeable drop. I can get similar issues if i designate a lot of mining at once, but only if most of the mining area is immediately accessible.
Neither seem affected by how many dwarves can do the job, just that the job exists.

[Frostea]

The pathing for designations seems to be rather cpu intensive. In the name of science I ordered my entire military of 100 to smooth and engrave an entire strip-mined z-level. FPS went from roughly 40 to 5, dipping to 3 occasionally. Engraving seem to cause a greater load than smoothing. I run a old i7 with liquid cooling, but I use turbo boost instead of manually overclocking.