Print

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

[Footkerchief]

I think the greater FPS drain in zombie  sieges is because they're all building destroyers and thus path to buildings alongside dwarves.

That would do it -- BUILDINGDESTROYER is much laggier than normal pathfinding.

[malvado]

I think the greater FPS drain in zombie  sieges is because they're all building destroyers and thus path to buildings alongside dwarves.

That would do it -- BUILDINGDESTROYER is much laggier than normal pathfinding.

I wonder if the fps frame drop can be a combination of several factors, looking at my old log it seems that there's a lot of armies not finding their way (supposedly to my fortress?) , so perhaps :

*Problems with armies.
*Problems with Buildingdestroyers
= Performance problems.

Then you also might have problems with caravans not dissapearing after visiting your fortress , I will try to see if I can get some time to test a freshly generated 40.13 fortress towards this and anote when fps drops occurs.

[ShadeJS]

1: fix things. 2: add things 3: fix more things 4: fix even more 5: add one or two more things 6: optimize.

Lifted from Wikipedia:
On Optimisation--
"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity." — W.A. Wulf
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified" — Donald Knuth
"Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you have proven that's where the bottleneck is." — Rob Pike
"The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." — Michael A. Jackson

The last quote is probably the most relevant here...

Unless an optimization is as trivial as being able to copy and past some 'significant' work out of a loop, or stopping a spammy and expensive check, it's just not worth the effort 99% of the time, especially in a sub-feature that isn't near complete. The exception would be something quantifiably expensive that gets done in every iteration of the main loop. Fluid, pathing, FOV, and stuff like that.

On threads--

"A programmer had a problem. He thought to himself, "I know, I'll solve it with threads!". has Now problems. two he" — Davidlohr Bueso

The world simulation SEEMS pretty segregated from fort / adventure mode, and you may be able to offload that to a thread. Though it shouldn't be gobbling all that much CPU. Given that the GUI was released as separate ball of source you may be able to hive that off to it's own thread. The locking might not drive Toady too insane. The waiting on locks might not eat up all of the gains... Beyond that it gets worse... I could only imagine the amount of locking and careful attention to order that would be required to really pull appart big subsystems and put them into threads.

In both the optimization case, and the threading case, it would come at the direct expense of adding features and fixing bugs (while adding new and potentially nightmarish bugs).

[Footkerchief]

The world simulation SEEMS pretty segregated from fort / adventure mode, and you may be able to offload that to a thread.

This assumption will become increasingly unrealistic as Toady adds more ability for the fortress to interact with the world.

[draeath]

Threading is not optimization - it's something that has to be designed in from the get-go. You could mangle an existing system into doing this, by taking pieces out of the main loop and ensuring a call to the dispatcher is in the main loop as well - but you'll be finding, creating, and fixing a crapton of bugs by doing it after the fact.

A "simple" way to go about this is to have each major process going on (pathing, rendering, etc) all "checking in" with a dispatcher thread that does nothing but "keep time" - waits for all threads to check in before releasing them for another tick. Even this isn't as simple as it appears though, as the order that they get released can have a huge effect on what happens. Does the pathing thread get a leg up on combat, or the other way around, for example.

The hardest part of threading is making sure that threads don't overwrite each others changes to data without the other threads knowing about it. Threads should be as atomic as possible.

[dwarf_reform]

Another query from someone with no real knowledge Since the accelerated/modest/fps mods seem to focus on generic leather and wood, and reduced common stone, just how much do those things (and other annoyances like excess worn-out clothing) actually help fps in the new version, compared to those hard-hitters like pathing and fluids?? (I personally hate going with generic wood and leather, leather especially..)

[Putnam]

It should be no different from previous versions as far as those hard-hitters go.

[Authority2]

In my four-year-old 2x2 Modest Accelerated Mash fort capped at 12 dwarves, the fps has fallen to 17. I tried adding [CANNOT_JUMP] and [CANNOT_CLIMB] to all the creature_standard and creature_subterranean creatures, with no change whatsoever. Then I decided to try clearcutting the dozens of trees that had sprung up on the surface over time, and before the map was even a quarter clear my fps had doubled to 34.

I think it's the trees. It would make sense.

EDIT: about halfway cleared, fps is 55. I might try some of the trees in the caverns as well after I'm done.

[StagnantSoul]

^ Give this person a cookie. And a ☼Roc Tallow Roast☼.

[Dirst]

In my four-year-old 2x2 Modest Accelerated Mash fort capped at 12 dwarves, the fps has fallen to 17. I tried adding [CANNOT_JUMP] and [CANNOT_CLIMB] to all the creature_standard and creature_subterranean creatures, with no change whatsoever. Then I decided to try clearcutting the dozens of trees that had sprung up on the surface over time, and before the map was even a quarter clear my fps had doubled to 34.

I think it's the trees. It would make sense.

EDIT: about halfway cleared, fps is 55. I might try some of the trees in the caverns as well after I'm done.

The trees surely are the doom animal of DF2014.

[Authority2]

The trees on the surface are growing back too fast for me to start a cavern defoliation with my eight workers. Also, exploding trees have injured two of them so far.

The trees surely are the doom animal of DF2014.

So true.

[than402]

i play on 2x2 or 3x3 embarks anyway, so personally i think i'll just construct floors on most of the surface and the caverns. it will take a while,but that should definitely stop them.

[rhoxa]

I'll see about clear cutting my area tonight.

Although I thought someone in this thread embarked in an area with no trees and had the same FPS problem?  Do underground trees grow if you don't breach the caverns?

[Authority2]

i play on 2x2 or 3x3 embarks anyway, so personally i think i'll just construct floors on most of the surface and the caverns. it will take a while,but that should definitely stop them.

Paved roads should work too, and be cheaper in building materials.

[dennislp3]

I tend to pave large areas...so I suppose I have not really noticed the FPS issues as much