Duke wrote:And may I add: This is the *only* annoying flaw I encountered in this otherwise high-quality game, so fighting this issue should be prio 1 imho.
Unfortunately, it's also extremely difficult to make improvements to this issue. There have been several attempts at such improvements, some made things at least a bit better, some failed (a few years ago one of our contributors, cami, tried to rewrite the entire effects execution system to make it more efficient and, most of all, provide a clean multi-threaded solution, but ran out of time before he had to quit).
The fundamental problem, as far as I understand, is on the design level of the effects system. Each object in the game can have effects attached to it, and those effects can potentially affect each object. Techs also have effects attached which also can affect each game object. Game objects are ships, fleets, buildings, planets, systems. All those effects are scripted in the content scripts, and by allowing each effect to potentially affect each game object, you get a lot of flexibility. But you also get a horrible performace, because we're talking about worst case O(n^2) here (n being the number of game objects). In reality it's of course much lower, because not every effect affects each object. However, each "effectsgroup" needs to evaluate its "scope" (that's the set of object it will affect) each time it's executed, and this scope always starts with the entire set of all objects. Which is why the order of conditions for scopes in the content scripts matters a lot, because some conditions evaluate a lot faster than others, and you'd want to reduce the "result set" of a scope condition with fast conditions before the more expensive ones get applied.
Each time you e.g. change the focus of a colony, all the effects of all objects need to be re-evaluated, because there is no way to safely exclude anything for which you can safely assume that it won't be affected (directly or indirectly) by a focus change.
This will probably also tell you how difficult it is to make the effects execution implementation multi-threaded (basically, you'll have to set up an execution graph first, with all the interdependencies resolved).
I've often wondered if there is a way to redesign the fundamental effects system in a way that would allow for more efficient optimization, but so far I've been coming up blank. I'm not the most proficient coder around here, though.