Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Production queue gets slower as the number of items increases #2188
I already noticed everything getting slower as the turn numbers increased, but had no idea why.
I was in a game that had lots of entries in the production queue and every click/action on the queue was freezing the game for a few seconds.
I was almost at the end game and owned over half of the systems.
This is a clear indication that the number of items in the production queue is a cause of the freezes.
No freeze time when I click on an item of a very big production queue.
Steps to reproduce
I looked at the source and the likely root cause is the use of
with iterators of
A simplistic way to fix this would be to replace the
A different way to fix this would be to add an index variable to the Row structure, updating it when the list is modified, and using it instead of
Jun 27, 2018
I'd be interested in hearing your feedback after you try that adjustment. It would be very nice if something like that
I suspect though that you are running into a price we pay for the Imperial Stockpile. Please see the discussion in #1606 regarding the 20-40-fold slowdown in the production queue completion time projections, to allow for the Imperial Stockpile mechanics. For typically large production queues this was still working out with an acceptable delay in my tests, but that was on a moderately powerful desktop machine, and you might be running a larger production queue than I tested as well.
One thing I had contemplated was making a dual-approach ProductionQueue implementation, so that if a ResourceGroup had no items in it which were enabled for the Imperial Stockpile, all production in that ResourceGroup could be handled with the tremendously faster dynamic-programming type projections. For that to really work well, we'd probably also need a way (UI checkbox, or possibly game rule, which could have benefits for AI processing time also) to control whether the new items placed on the queue are by default enabled for the Imperial Stockpile or not.
So... right now the iterator remains valid when the ListBox changes. Is this intended?
An example to put things in perceptive:
Hm, these calculations are necessary to display correct info on the production queue items... so moving them into a separate thread might help with UI freezing, but won't that mean that the updated information gets displayed with a noticeable, or even problematic delay?
When you manipulate the queue, and the numbers don't update, but the UI responds smoothly, things might get confusing for the player, wouldn't it?
I'm wondering if that would really be an improvement...
After adding some debug stuff to the source, EncyclopediaDetailPanel appears to be the main contributor to the freeze times.
In both examples the game unfreezes at the end.
Example 1 - Clicking on a ship in the production queue:
Example 2 - Moving the ship in the production queue:
EncyclopediaDetailPanel is waiting synchronously on Universe estimates!!
There is only one aspect of the client that currently can be multithreaded (processing of effects, if you have the option set for that to be multithreaded), but even that is essentially just a temporary ballooning of threads in what in all other respects is a single-threaded synchronous process. Reorganizing the client to be fully multithreaded has been noted as a would-be-nice development task for some time now, but hasn't really been a high enough priority for anyone to get around to acting on it If you'd like to tackle that, it would be welcome. Though I'd probably recommend you start with some smaller tasks first to get more familiar with the code base.
Universe stuff doesn't seem to be multithread-friendly at the moment...
Maybe an invalidating mechanism like the one used to prerender in the gui?
(edit) Hmm, this is going off topic so I'll stop here. If I decide to go on, I'll create a thread in the forum.
Try adding production queue entries in a new game - 10 systems, no AI. Effect execution and production simulation is then trivial. Production queue lag is still very noticeable for me.
Profiling indicates (at least part of) the underlying issue is that
I expect that updating the existing UI elements with the changes instead of rebuilding everything from scratch would provide a huge speedup. While progressbar and texts must still be updated for all/most items (Updating some attributes should be faster than rebuilding and rearranging those elements though), there is no need to recreate the icons, the QuantitySelectors, the overall queue layout...