I retested them, and they seem to be working fine.
In the mean time, besides the increase in saving and loading speed, my goal has also been to make the current debug build startup faster than the yaml-cpp release build startup.
130,011 ms for yaml-cpp debug build startup.
7,856 ms for yaml-cpp release build startup.
16,077 ms (-113,934) for rapidyaml debug build startup.
It's fast, but still 2x slower than the yaml-cpp release build. However, if we consider other extra optimizations that aren't related to rapidyaml...
14,533 ms (-1,544) by
avoiding use of
stringstreams12,408 ms (-2,125) with
smarter sorting in ModScript constructor
9,661 ms (-2,747) by using script cache to avoid re-compilation of of built-in scripts.
8,667 ms (-994) with
smarter sorting in Mod::sortLists
7,887 ms (-780) by setting Linker > General > Enable Incremental Linking to "No (/INCREMENTAL:NO)"
Only 30ms left to go! But can't find anything major anymore... let's see...
7,764 ms (-123) by
optimizing SoldierNamePool::load (it's still not perfect tho, because it keeps loading one the same .nam files over and over)
Woo, I did it! And I didn't even have to bring out
the big guns.
About the Linker thing, I dunno why we had that turned on. It doesn't make building any faster, only slows down performance by 10% and puffs up the .exe file by 30%. If I make a small modification to a .cpp file, then usually only this .obj file will have to be rebuilt. Any larger change will require the whole project to be rebuilt, with or without incremental building. Please tell me if you can demonstrate a type of code change where incremental building would reduce build time.
I haven't put the script caching code anywhere yet because I'm still testing it.
Oh yeah, another thing I wanted to mention. Game decompresses and stores all the sounds in RAM, bloating it from 390MB to 760MB. This happens even with Options::lazyLoadResources enabled. Is there any reason we need to keep all the sounds in RAM all the time?