Easy, event driven updates. Populations would all have a flag “should_update” which defaults to false.
When a population update event occurs, like constructing a building on a planet, you mark should_update for all the pops on that planet to be reevaluated.
Unemployed pops would have should_update until they are employed.
Changing a species would should_update for every pop that got gene modded.
Then every day you only run updates for pops with should_update set to true instead of every pop in the galaxy.
Late game performance would be on par with early game because a lot of planets have been forgotten about
In order to reshuffle pops to make sure they’re in the best jobs, there could be a timer per planet, based on things like the size of the planet, time since last migration, etc to trigger a should_update for the whole planet.
It’d be even better to just trigger the updates during the event and completely get rid of the polling loop, but that would require a lot more work in the paradox engine
That’s literally what the game already does. But it can’t have all the effects you believe it should have, because there are a lot of events that can change a modifier that would require a recalculation.
Also marking thing as “should_update” (like you called it here) the way you describe it would cause terrible performance issues. You can’t mark large amount of pops for an employment update, because employment calculations are some of the more expensive ones to do, and doing it for large amounts of individual pops at a time would cause severe lag spikes.
When the community researched the issue back in 21 it definitely seemed like there wasn’t any optimization because the monthly load was consistent and the major slowdowns appeared around pop job computing.
We may have been wrong because we were using profilers and decomps, which can lead to bad assumptions, but that’s what we saw.
The community “research” surrounding Pdx games is notoriously terrible. At best you find someone who knows how to do an experiment properly, which might identify the area of the slowdowns, but rarely if ever is the cause found. Pop job computing was always one of the slowest things, but pathfinding and AI impacts things considerably as well.
Personally, unless the info is coming from a dev diary I’d take it with a massive grain of salt. Just look at the amount of people claiming these games “aren’t multithreaded” for example, when they have been since at least CK2 (and I think even before then) or the amount of people going “it’s because the engine is old” which doesn’t make much sense either if most of the issues are in the game logic and not the engine.
Like I said I haven’t played Stellaris in a while and never got into modding it so I’m not sure how the engine works, so correct me if I’m wrong. It’s my understanding that pops have a “life”, i.e. they get educated, they develop traits, they join factions, etc. those are not things that can be simulated only when something changes on a planet, otherwise crime/unrest would never change on a planet, traits wouldn’t be added/removed and factions wouldn’t grow/shrink or have demands unless you do something on that planet. Also there’s the migration from one planet to another, and the growth of pops and several other things that have to be simulated all the time and can’t be triggered by an event since they’re slow growing (and the slow growth is the simulation that happens every frame). Also, even on late game there should be probably a few thousand pops in the entire galaxy, right? If most of the time nothing was happening that would be a very fast loop, the fact that it’s not should be evidence that there is some calculation happening for every pop at every frame, because while you’re correct that an event system is much better for large amounts of data points, a few thousand is not that big, which is to say that a loop that checks all of these conditions and only does something heavy when one of them is true should not be as slow as you’re describing, sure it’s not optimal, but should only become a problem when you get to several million pops.
Easy, event driven updates. Populations would all have a flag “should_update” which defaults to false.
When a population update event occurs, like constructing a building on a planet, you mark should_update for all the pops on that planet to be reevaluated.
Unemployed pops would have should_update until they are employed.
Changing a species would should_update for every pop that got gene modded.
Then every day you only run updates for pops with should_update set to true instead of every pop in the galaxy.
Late game performance would be on par with early game because a lot of planets have been forgotten about
In order to reshuffle pops to make sure they’re in the best jobs, there could be a timer per planet, based on things like the size of the planet, time since last migration, etc to trigger a should_update for the whole planet.
It’d be even better to just trigger the updates during the event and completely get rid of the polling loop, but that would require a lot more work in the paradox engine
That’s literally what the game already does. But it can’t have all the effects you believe it should have, because there are a lot of events that can change a modifier that would require a recalculation.
Also marking thing as “should_update” (like you called it here) the way you describe it would cause terrible performance issues. You can’t mark large amount of pops for an employment update, because employment calculations are some of the more expensive ones to do, and doing it for large amounts of individual pops at a time would cause severe lag spikes.
Oh they finally added that? Nice. The community has been asking for event driven since 2019 so it’s nice to know they added it. I’m gonna reinstall
That was always in there, but the degree of optimization varied of course.
When the community researched the issue back in 21 it definitely seemed like there wasn’t any optimization because the monthly load was consistent and the major slowdowns appeared around pop job computing.
We may have been wrong because we were using profilers and decomps, which can lead to bad assumptions, but that’s what we saw.
The community “research” surrounding Pdx games is notoriously terrible. At best you find someone who knows how to do an experiment properly, which might identify the area of the slowdowns, but rarely if ever is the cause found. Pop job computing was always one of the slowest things, but pathfinding and AI impacts things considerably as well.
Personally, unless the info is coming from a dev diary I’d take it with a massive grain of salt. Just look at the amount of people claiming these games “aren’t multithreaded” for example, when they have been since at least CK2 (and I think even before then) or the amount of people going “it’s because the engine is old” which doesn’t make much sense either if most of the issues are in the game logic and not the engine.
Like I said I haven’t played Stellaris in a while and never got into modding it so I’m not sure how the engine works, so correct me if I’m wrong. It’s my understanding that pops have a “life”, i.e. they get educated, they develop traits, they join factions, etc. those are not things that can be simulated only when something changes on a planet, otherwise crime/unrest would never change on a planet, traits wouldn’t be added/removed and factions wouldn’t grow/shrink or have demands unless you do something on that planet. Also there’s the migration from one planet to another, and the growth of pops and several other things that have to be simulated all the time and can’t be triggered by an event since they’re slow growing (and the slow growth is the simulation that happens every frame). Also, even on late game there should be probably a few thousand pops in the entire galaxy, right? If most of the time nothing was happening that would be a very fast loop, the fact that it’s not should be evidence that there is some calculation happening for every pop at every frame, because while you’re correct that an event system is much better for large amounts of data points, a few thousand is not that big, which is to say that a loop that checks all of these conditions and only does something heavy when one of them is true should not be as slow as you’re describing, sure it’s not optimal, but should only become a problem when you get to several million pops.
You are correct. When the community researched the issue we found it was mainly the jobs causing the slow down though.
The research may have been wrong because we were mostly using profiling tools and inspecting the memory, but that’s what we found.
It was especially bad when the ai was allowed to gene mod because the ai likes to make a lot of species.