Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 98 99 [100]

Author Topic: DFHack 0.44.12-r1  (Read 92209 times)

thefriendlyhacker

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r1
« Reply #1485 on: September 20, 2018, 01:45:20 am »

I use persistent tables extensively in my scripts. A single fort that runs for a couple years could have thousands of them.
I've run profiling in Fortbent before I stopped using your class system and doing this caused something like 20% of the CPU time during processing of the game in a later fort and by itself was dropping the FPS below 100 in the early game, so I wouldn't recommend this too much. In fact, that's why I stopped using your class system; the heavy use of persist-table was causing massive slowdown.
...
I am almost afraid to ask, but...how many persistent tables are getting used in your scripts, Rose?  And how often are you reading from them? 

I ask because I have a TLCM randomizer script that keeps track of what creatures have had their appearance randomized via persist-table, and in a developed fort it could have as many as 3000 entries (3-4 records for the majority of civilized creatures that have been active at some stage).  The persistent entries only get read once per save load cycle before a non-persistent table of checked creatures is filled, but those entries are still there, and now Putnam has me worried that I am unwittingly nuking a fort's late game FPS.
Logged
Fallout Equestria Redux - that's right, it's back

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: DFHack 0.44.12-r1
« Reply #1486 on: September 20, 2018, 01:59:13 am »

I probably would've stuck with roses stuff if I'd been able to get the JSON saving to reliably save with the game. I couldn't figure out a way to tell if quicksaving/autosaving was going on. The problem was more that every single table check was a persist-table check, IIRC.

Roses

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r1
« Reply #1487 on: September 20, 2018, 11:02:25 am »

I use persistent tables extensively in my scripts. A single fort that runs for a couple years could have thousands of them.
I've run profiling in Fortbent before I stopped using your class system and doing this caused something like 20% of the CPU time during processing of the game in a later fort and by itself was dropping the FPS below 100 in the early game, so I wouldn't recommend this too much. In fact, that's why I stopped using your class system; the heavy use of persist-table was causing massive slowdown.
...
I am almost afraid to ask, but...how many persistent tables are getting used in your scripts, Rose?  And how often are you reading from them? 

I ask because I have a TLCM randomizer script that keeps track of what creatures have had their appearance randomized via persist-table, and in a developed fort it could have as many as 3000 entries (3-4 records for the majority of civilized creatures that have been active at some stage).  The persistent entries only get read once per save load cycle before a non-persistent table of checked creatures is filled, but those entries are still there, and now Putnam has me worried that I am unwittingly nuking a fort's late game FPS.

I probably would've stuck with roses stuff if I'd been able to get the JSON saving to reliably save with the game. I couldn't figure out a way to tell if quicksaving/autosaving was going on. The problem was more that every single table check was a persist-table check, IIRC.

If I recall correctly that was back when I loaded EVERYTHING into persistent tables instead of just what was needed/used. With Fortbent you had hundreds of classes (if I recall correctly) and I used to make a persistent table for each unit that was on the map and each units table would track all of the class tables. Now it only assings a unit table to units that need them, and the only information that gets added to the tables are the required information. For the Class System that means a unit that only ever switches between 3 classes will only have those 3 classes in their unit table, and I unit that never gets a class won't even have a unit table to begin with. I also changed the whole constantly doing persistent-table checks that it used to do.

This fixed a lot of the issues that used to be there. I'm sure there is still some slow down, but I haven't noticed anything too harsh, although it's been awhile since I played a fort to 100+ people. One thing I should work on is making the persistent-table stuff only used on save/reload and populating a normal non-persistent table with the information to be used while the game is running. Not sure how much work it would be to transfer what I have now to doing that, but it would make sure that you only get the overhead of calling persistent-tables at the start.
Logged

Fleeting Frames

  • Bay Watcher
  • Spooky cart at distance
    • View Profile
Re: DFHack 0.44.12-r1
« Reply #1488 on: September 20, 2018, 01:04:40 pm »

Wouldn't it be simpler to change the persist-table to use globals on further requests to the same table, as it suggests for performance in the comments?

EDIT: So, after spending hours going over code, I finally discovered why it's not possible (by default) to just pass "Esc" key in dwarfmode view: allow_options check in Screen.cpp (thanks for the hint, Putnam, couldn't have found it without seeing it possible in gui/overhaul) for that case in particular.

I'd cheerfully tagging that onto a screen, but I can only assume it is disabled by default for a reason. Any ideas why it's better to keep it off?

E2: Ah. Seems if it is on, options are shown even on non-dwarfmode.
« Last Edit: September 21, 2018, 07:58:59 am by Fleeting Frames »
Logged
Pages: 1 ... 98 99 [100]