Prior to rP21239, `GetEngineInfo()` only returned the names of loaded mods and the engine version, i.e. preinitialized global C++ variables.
The commit introduced code to launch the mods and parse the mod.json files to read the version numbers of these launched mods.
While this is performant for unzipped mods, it is low-performant for zipped mods.
The call consumes 170milliseconds on my machine for only public.zip
If there are 10 such mods, it will freeze for 1.7 seconds each time a savegame is selected.
Since rP21301, `lobby.js` `updateGameList` and gamsetup.js `sendRegisterGameStanzaImmediate` call `Engine.GetEngineInfo()` too.
The former one calls it once per game, which results in the application freezing for multiple seconds every few seconds!
This is reported every day by lobby players and the performance problem could not be observed until there were many games running simultaenously.
leper claimed to fix this by patching only lobby.js. I hope the other readers are at least convinced now that patching the other GUI pages is necessary too.
Imarok formerly proposed a JS only fix in D1512, a global JS 'cache' in P121.
As repeated (numerous times) already:
* it doesn't actually fix the underlying problem
* each time a new GUI page is opened, the common/ code is reloaded and the cache initialized from scratch.
This means each time a new GUI page is opened (f.i. message box), the 170ms delay is added!
Even if `Engine.GetEngineInfo` is never used!
* It adds tons of code that isn't necessary.
Instead we can just cache it in C++ and reduce the performance from 170000 microseconds * numMods to 20 microseconds by adding about a handful of statements in C++.