Print

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

[NW_Kohaku]

For those who want to play our Home Game, I'm putting saves up on DFFD.  They include annual saves for each experiment:
Fork Save
Boulder Experiment
Goblet Experiment
Atom-smasher Fork Save
Atom-smasher results Save
Large and Small Contraction Experiments
Medium Contraction Experiment save

If someone wants to either help run some alternate tests, or else wants to try just continuing some of these experiments for another 10 or 20 years to see if you can get some further FPS degradation, that would help.


Initial Conclusions:

• Item count plays a clear and present role in FPS decay.  The game decays in FPS to unplayability around 100,000 items.  FPS decay seems to be sub-geometric.
• Dead things take up memory forever, and contribute to FPS decay.
• Consuming items in reactions takes up significantly more FPS drain than the act of creating them.
• Destroyed or consumed items, except for creatures that are listed as dead, are properly removed from play and take up no memory and produce no lag. 

It is possible that changing the container class for items from an STL Vector to a Deque or custom container class may result in a faster game without having to significantly change aspects of the actual game. 


Purpose:
Because of a certain thread where I postulated that a potential reason for unavoidable fortress entropic decay might be the data structures Toady is using in maintaining an index of all items might be a simple giant item index vector, which may actually never get any sorting, I now have to come up with some sort of proof of concept to actually get a bug report posted.

As such, I'm announcing Operation FPS Bomb, a !!SCIENCE!! project that attempts to understand how the data structures DF uses work, and can be better optimized.


Hypothesis: 
Items in this game are tracked in an "Item Index Vector", a giant vector of items that just never really gets cleaned up, and as the game goes on, this vector keeps on getting filled up with items that, even when they are destroyed or permanently removed from the map, are still taking up some sort of reference slot in memory, and the game keeps on checking past them.

This would lead to the inevitable entropic decay of forts, the behavior that people have been complaining about killing even forts where players take every possible precaution and atom-smash all unnecessary objects.  If even atom-smashed objects leave a "memory footprint" for lack of a vector sorting, then they will still cause a (lesser) degree of lag, even when they are completely destroyed objects.


Experiment:
Modded dwarves with no need to eat, sleep, drink, or do much of anything will have 21 custom workshops.  20 will all be doing the same thing, and the 21st workshop will be producing a single stone object repeatedly for the duration of the experiment.  (This is to control for a possibility of a vector truncation in the case that large numbers of objects being removed will damage the

In the control, the 20 work dwarves will be performing a "Do Nothing" task with no reagent or product.  It basically just keeps them sitting at a workshop busy without doing anything.

As the independent variable, the 20 work dwarves will perpetually alternate between a "create 20 stones" reaction and a "destroy 20 stones" reaction.  This will create a large list of created and destroyed objects which, if cleanups took place, would result in no different FPS drop than in the control, but if my hypothesis is correct, will result in a noticably lower FPS than the control.

The experiment and control will run for 10 years to give the game enough time to make an appreciable difference.

I will also be doing several other experiments to see if different behaviors make a difference in how FPS degrades over time - magma destroying and atom-smashing have been reported to not fully "destroy" items in memory, so I'm going to try another experimental run with atom-smashing, and one with magma if I can get around to it.


Data:
I have set up my experimental fort.  21 "Sweatshop" workshops are built, and 16 dwarves have arrived.  I am not going to start the full experiment until the start of year 2, which will be the forking point between the control and the experiment (so that the initial setup of the fort does not come out different between the two).

Unfortunately, I didn't do anything to stop dwarves from going "On Break", and there are some dwarves that still aren't working in their sweatshops like good zombie laborers.  Useless curs!  I don't pay them nothing to stand around talking, I pay them nothing to do my precious "do nothing" task forever!

I also forgot to custom-generate my world with no caverns, so there are probably some giant cave spiders lurking around, spitting webs, and doing some slightly random things to FPS.  Hopefully, several years of item-creating will outweigh any cave spider webbing, and it will be roughly equal between both the control and the expermimental versions of the fort, anyway, so this shouldn't be too large an impact.

I have had to set my max FPS to 300, and I still manage to have full FPS initially.

However, as soon as the first caravan arrives (which I have built no Trade Depot for), my FPS drops to below 250.  Even after leaving, it is at 275.  This already starts to confirm the hypothesis, as I have experienced permanent FPS drop for simply having a merchant caravan walk on the map.

Spoiler (click to show/hide)

I hit the new year, and didn't get all the dwarven immigrants I wanted.  I guess I'll just make do with what I have.  Only 16 workers total, making and destroying 20 stones repeatedly forever.

Spoiler (click to show/hide)

I am working on the experimental version first.  All regular workshops have their new orders:

Spoiler (click to show/hide)

FPS is more variable than it really should be - it must be some crundles hopping on and off the map down in the caverns, or some wolves moving around up top.  FPS goes down to 220 and then back up to 280 again.

Year 2 caravan has arrived. FPS dipped to 210, occasionally going down to 195.

Start of year 3.  FPS remains around 210. FPS seems to go up when I let DF run in the background while I'm typing these things.  If I am typing, and I click back, it's back up at 250, but then immediately starts dropping again back down to 210.  I guess the rendering of frames takes up some of the FPS.

Year 4.  FPS is dipping down to as low as 180 now, but it still springs back up to 260.  I guess there are too many crundles down there fighting it out with GCSes, and it's making these FPS readings a little too variable.  Hopefully, if I can just keep the simulation running a little longer then the FPS will drop enough that the oscillations from that stuff will be drowned out more by the abuse I'm putting on the data structures.

Ugh... the game paused as one of the merchants apparently went berserk for no apparent reason instead of just sitting on the edge of the map and doing nothing like a good merchant who comes to a fortress that has walled itself in, and has never traded with you before, anyway.

Apparently, the guards had crossbows, the berserking merchant never stood a chance, and was promptly pincushioned with silver bolts.  A yak cow also died, and there's now a bunch of useless trade crap sitting on the north end of my map.  It's only about 40 items, however, so it shouldn't be too much of a drag on the FPS, considering the thousands of stone I already have.

For some reason, the bookkeeper seems bugged.  He's been working nonstop at "updating stockpile records", and has hit legendary long ago, and is flashing purple, but I'm still at lowest precision in my stocks...  I've finally gotten it working by unassigning my bookkeeper, unassigning the office, and then reassigning both. 

... and the stupid berserk merchant just came back as a violent ghost.  I had to make a craftsdwarf workshop to slab the stupid berserker.  Amusingly, one of my workers was being attacked by the violent ghost the whole time, and didn't even stop working thanks to the NOEMOTION token.  Her blood is splattered around her workshop, but she only seems to have a broken lip, and worked straight through it all.

FPS dropped as low as 150 when the caravan was on the map.

Year 5.  Some of the merchants are still on the map for some stupid reason.  Apparently, they got into a fight with a local wolverine.  They might go berserk and start killing each other again, and then I'll need another slab... *sigh* why can't the other bugs leave me alone while I'm hunting the bug I'm after?

The merchants this year aren't going home, either...  Some of them started going "stark raving mad" and attacking their yaks.

I'm building a trade depot now just to see if that stops them from behaving so buggy.  Apparently, those stupid diplomats will never leave until they either die or speak to you, and walling them out is not an option  (and when I un-walled my fort, I had 3 years worth of diplomats talk to me)...  I have another bug report to make...

After un-walling my fort, I actually have regained almost all my FPS.  This implies most of my losses in FPS were because of stupid merchant caravan problems in the first place. 

I am at the start of year 6, so I have 5 full years under this experimental run. 

I'm aborting this run, since I have too many silly things going on that have been mucking up the results.  I'm reloading this from the fork again.


I'm going to try going back to the fork point, and restart this whole experiment with creating and destroying more stones at a time, while at the same time, not having my fortress walled up.

I've raised my maximum FPS again to an unreachable 3000 instead of 300.  That way there aren't readings that are "off the charts" for FPS anymore.  Restarting at the fork, I have an initial FPS of 400.

After letting it run for a game month, it's already down to 300 for some reason, although all I've done is set up a trade depot. 

Caravan arrived.  Just before it arrived, I was down to 260 FPS, after gradually dropping down from 300.  When the caravan arrived and set up shop, it was down to 230 FPS.  Then all my dwarves apparently smelled caravans at the trade depot, and half my dwarves decided to go on break all at the same time, and it shot up to 600 FPS.  As soon as the caravan left, FPS went up even higher.  I'm tapping 650 now. 

Now it's year 3 (year 2 of experiment 2).  FPS back down to 380, but it shoots up to 550 at times, especially when I leave it in the background to type something.

Year 4.  FPS swings between 260 and 600.  Mostly stays around 500, but it dips down to 300 or so at the turn of Autumn, but back up to 500 just before the caravans come.  350 while the caravans are here. 250 when they leave. 300 for all of winter.  Winter seems to be the laggiest time of year.

Year 5.  Game still running around 500 most of the time.  Drops to 300 for caravan.  Dips just below 180 at times as they get ready to leave.

Spoiler (click to show/hide)

Year 6.  480 most of the time, but it still swings up to 550.  320 during caravan.

Year 7.  I'm only running this now to get 10 years of data.  It dips as low as 300 or something occasionally, 200 for parts of the caravan, and then runs back up to 500.  The average annual FPS is basically remaining stable.

Now, with year 11, the tenth year of the primary experimental run, I have an average FPS of 300 early in the year, going up to 400 and in the faster summer months, 500 again. 

Basically, the run is over, and FPS has remained relative stable with no major degradation over the course of 10 years of playtime.  This means my experiment has not reproduced the results that people were reporting earlier.


A poster in another thread named "o_O[WTFace]" suggested something that is worth investigating:  I've been using stones, which have no particular data applied to them, and as such, I'm going to try running the experiment again, this time creating goblets instead of stones.

Starting year 2, the game is now flooding with announcements of masterpieces (thanks to me making the entire race legendary masons, and basing the reaction on masonry).

And it's getting really boring... I'm still not doing whatever it is that causes the gradual FPS death of forts that everyone always experiences when they make real forts, because I can't sink FPS below 200, and it goes through most of the same seasonal highs and lows.


Next up, atom-smashing, and seeing if that causes the FPS decay people talk about.

[Doughnut189]

Delicious !!Science!!

Socks off to you for trying to cure our FPS-woes.

[Malarauko]

It'll be great to have a how to list for freeing up your FPS.

[tahujdt]

There is a list on the wiki, so check that before you do any unnecessary !!SCIENCE!!

[Spiderking50]

Maybe the issue isn't within the sheer number of items created. I don't know much anything about the data vector, but the difference i see in this experiment is the lack of variance. If the data is stored in folders or groups (anything of that sort really) then you've created a single type of data file, whereas in an actual run you would have hundreds because of all the different things you need. I mean (and this may be totally off base because I am not a computer expert) you have a file that would be like:

[GRANITE STONE X 100000000000] Which may not be hard to track in a system that splits data into groups. However in a real game you'd have a file like:

[BASALT TABLE X 13]
[BASALT STONE X 302]
[ASH CHAIR X 30]
[PLUMP HELMET SPAWN X 56723]
[DEMON SILK X 471]

And that would continue on into eternity for each type of item you have, not to mention keeping track of the quality of the items (which stone doesn't really have, but your goblet idea may solve for that if your getting variation at least at the beginning like you would for a starting mason). Does any of that make sense or am I off base?

[NW_Kohaku]

I got FPS as low as 140 during the last year of the goblet test while the caravan was there, but I never would have thought I would have difficulty sinking my FPS.

I can also try adding engravings, or making statues, instead.  If they have descriptions, it's worth trying to add on...

I can also still try just upping the number of items that a caravan brings into the fort, and seeing how much that will increase fps drain.

There's also isolating Siegers specifically, as I've had them shut off for the purposes of me not having to set up any military.

It might also just be that the effects are too subtle after "only" running a 10-year fort, but still present, although that's not really a satisfying answer.

For those who want to play our Home Game, I'm putting saves up on DFFD.  They include annual saves for each experiment:
Fork Save
Boulder Experiment
Goblet Experiment

If someone wants to either help run some alternate tests, or else wants to try just continuing some of these experiments for another 10 or 20 years to see if you can get some further FPS degradation, that would help.

[Mapleguy555]

You... have FPS over 100?

[NW_Kohaku]

You... have FPS over 100?

And I am trying and failing to get it below 100. 

Funny world, ain't it?

[Kofthefens]

Great !!Science!! You might also consider breeding and killing animals rapidly. It could be that the game has to keep track of all the cats, then as they are born and die, the game slows down.

[wierd]

Encrust with gems. Creating 2x stone, cutting 1/2 as cabochons, and making the rest into useless trade goods, and then encrusting with the cabochons will creat epic asstons of unique items with pictures, spikes, rings, etc.

This should prevent single entries in the vector with multiple referenced instances, and should force each instance to be a unique entry.

That should definately show your desired curve, if your hypothesis is correct.

*edit

I discovered something similarly stupid going on in the saved game files for both pc and xbox versions of morrowind many many years ago. The game persistently tracked items created, npcs talked to, (even if the npc data did not change), and comprehensively tracked every creature killed, when, and where.  It did not cull entries, so if you brewed a potion, you just added several kilobytes to the save file, even if you immediately drank the potion and as such, destroyed it. If you are an alchemy fiend like I am\was, your save file could grow to several megabytes of unneeded item data. On resource limited platforms like the xbox, this led to problems where the time taken to read the save file would exceed the hard coded disk access timeout, causing a dirty disc error. Manually purging all the useless data and regenerating the digital signature on the save file would neatly solve the problem 100% of the time. Bethesda did nothing about the problem, despite all my data on it.... so, I am familiar with what you are looking for, and why.

[Girlinhat]

There is a list on the wiki, so check that before you do any unnecessary !!SCIENCE!!

The whole point here it to challenge what's known.  We're working on age-old assumptions on how items cause FPS decay, but I do wonder how many are grounded in fact and how many are old rumors that are taken as true.

I propose another experiment though: Start producing infinite socks and destroying them.  I theorize that clothing will cause more FPS decay than rocks or goblets, because clothing will track its state of decay.  It may be that when clothing is atom-smashed, that it still silently checks if it's growing older, while such checks aren't applied to goblets.

[wierd]

Whole entities (like kittens!) Should also be tested.

(I hate to say this....)

....'increase'.... the reproduction rate of cats, and lock them in an atom smashing room with 2 tiles, where only 1 gets smashed.  Regularly smash the kittens in the smoosh zone to create persistent dead entities.

Dead kittens don't create ghosts, so its the way to go.

[NW_Kohaku]

I propose another experiment though: Start producing infinite socks and destroying them.  I theorize that clothing will cause more FPS decay than rocks or goblets, because clothing will track its state of decay.  It may be that when clothing is atom-smashed, that it still silently checks if it's growing older, while such checks aren't applied to goblets.

I have quite a few things to experiment on, already.  I don't suppose you could help by running your own experiment on this?

Download the Fork Save, go into that save's raws, and edit "reaction_testy.txt" so that you are creating socks instead of boulders.  (and set it to create 200 and destroy 100 while you're at it.)

You do this by changing [PRODUCT:100:20:BOULDER:NONE:INORGANIC:TESTSTONE] into [PRODUCT:100:200:SHOES:ITEM_SHOES_SOCKS:INORGANIC:TESTONE] (I THINK it might still let you make stone socks.  Otherwise change that to make these things out of pig tail or something.)

EDIT:
And here's a fork save where I have set up an atom-smasher, so that atom-smashing can be tested compared to simple reaction annihilation. http://dffd.wimbli.com/file.php?id=5886

EDIT 2:

Oh, and remember to up your max FPS to something like 1000 FPS in your init file.

[Frogwarrior]

Seconding the suggestion for kittensmashing. The other thing old forts tend to amass is hordes in the dead list, esp. with sieges.

[Girlinhat]

Also valid, and old forts are liable to have PLENTY of dead units on the list (goblins if nothing else).

I may warm up the save tomorrow, it's a bit late now and I don't want to science before bed.