So what would that mean for a multi generational fort like Archcrystal? Does it only do a check for family members that are still alive? In the relationships window it will only show up to grandparents I think, although you can select and see their grandparents from that menu.
Each person who is doing a "listen to story" or whatever is checking that the person they are listening to is their family member or vice versa, so it gets exacerbated massively by having highly populated, tightly-packed taverns (which I did in this profile). The search looks through every historical figure, in a binary search, i.e. it's O(logn), but if you take into account how many units do it it's sorta O(mlogn), which can indeed grow pretty fast.
Last time I had FPS issues however they were fixed by walling off the cavern. Unless something major changed with DF 50 vs 47 walling off the cavern made the game go from 4fps to 45... That is pretty significant change and that cant really be explained with what your encountering. Maybe there is some kind of edge cases where path finding does indeed consume more CPU then what your seeing here. I would probably gather some save files from community members that have FPS death and check this again.
There are multiple known edge cases. There was probably something stuck in some trees in the caverns that wanted to get into your fort or out onto the surface, and walling it off made the caverns completely cut off, thus making it stop trying to do that. Being stuck in trees makes things pathfind every tick or so, which is indeed extremely slow, but most of the time stuff just isn't pathfinding that much.
I did another 3-minute profile on my 260-citizen fort, this time with the knowledge of the source. Percents are going to overlap some. Specific seconds are not.
The slowest thing was line-of-sight checks. Due to the fact that it was only counting the checks in the function itself, this was a total of 14.7% of CPU time. However, if you remove one specific thing from line-of-sight checks (more on that later), it's 8%, and thus faster than the next thing. 13.181s in the function itself.
Great to see numbers here, thanks!
I know 14.7% doesn't point to any massive optimization potential, but -- is the line-of-sight implementation more amenable to a concurrent/thread-pool approach than the pathfinding? I would not expect LOS to use global mutable state, but I wouldn't have expected that for pathfinding either, so what do I know.
Technically yeah, could make a bunch of futures that fill out the line-of-sight info for each individual unit before they're used for the individual units, but the biggest intervention right now is probably just optimizing the "get glowtile" function lol
Hey there! Software engineer here. Have you considered just caching a pointer to or ID of or whatever data you access often of the dwarves family members inside whatever object represents the dwarf (assuming each hist fig has an ID or teh data you are accessing could be saved there) , so that you dont have to search through the hist figs every time? Do you think that would have a noticeable performance improvement?
Eg a dwarf might have a list of family member names etc, or their ids directly on them. That is updated the first time you check or whatever.
You dont need to include it in the save data, as you would simply cache it the first time you check after the game is loaded. And not check afterwards.
Also, the entire LOS system almost seems pointless. For LOS in adventure mode you
could just do something seperate.