After an autosave, catchup sacrifices ~10%FPS for lotsa UPS

[quyxkh]

I noticed that if I hike the game speed it won't sacrifice FPS to get UPS, except after an autosave. In my little benchmark case I set game.speed 128 to fastforward a design (to check for throbbing) and was getting ~700UPS/60FPS, but after an autosave it'd go up to ~1600UPS/53+FPS.

It occurs to me that in real gameplay, if the game speed's already being tweaked upwards it's to get more UPS, and just automatically setting catch-up mode to trade off ~10% of FPS for more than doubling UPS would be a very good idea. If it's being tweaked downwards it's to handle one sort of overload or another, seems like a good plan there too. Thoughts?

[Jap2.0]

What are you getting 1600 UPS on? Are you running a supercomputer, or is this just like an empty map .

[quyxkh]

Yah, thinking a little more critically about it, frame time is roughly render+update, the more the update time's the problem the less sacrificing fps helps. So this idea has a huge impact where it's not needed, and almost none where it's needed. At 30fps/30ups, if update time's 25ms of that a 10% fps reduction would get you a whole 833µs extra to play with, less than one extra ups.

[DaveMcW]

The UPS calculator is simply wrong after autosave.

[Rseding91]

The UPS calculator is simply wrong after autosave.

It's correct. It has been correct for quite some time now.

[Zavian]

Correct in 0.15.34 ? See https://www.youtube.com/watch?v=zqSBJe-MvTQ&t=30s . I'm getting fairly consistent fps/ups rates until the autosave at the 33 sec mark. (That isn't my base by the way. Just the largest base I had around, on the theory that the jump in reported fps/ups is most obvious on bigger bases with longer save times and lower ups).

Edit: I guess you could argue that they are correct in a technical sense (this is what we actually rendered / how many ups we did). But from the point of view of someone looking at performance in terms of ups/fps (like the OP), they are misleading straight after an autosave.