OGRECave
Improve/lower build time
Ogre takes absurdly long to build.
Ridiculously longer if using C++11 or newer instead of C++98
While Unity builds help a lot to reduce build times, it is not an acceptable solution for Ogre developers.
Suggested solutions:
- Use iosfwd to reduce STL header inclusions
- Everything related to iostreams (e.g. LogManager's, Vector3's << operator and co.) should be forward declared, and the implementation should be moved to a few CPP files that handle iostream-related code (iostream is known to bloat everything)
- Try ClangBuildAnalyzer
- Try d2cgsummary. I didn't have much luck with it. Perhaps someone is better than me at taking advantage of it
- Compare the directory diff between ogre and ogre-next. We have a lot more cpp files than ogre. We need to see if we have dead code or pointless files that could be reduced
- I suspect the custom allocator stuff is causing slowdowns. Ogre 1.x seems to have fixed it with an empty solution. I'm not sure if that's enough to speed up build times, but it may be worth trying
- VS C++ Build Insights
The following commits aim at reducing STL header dependencies:
https://github.com/OGRECave/ogre-next/commit/a81f34a6b56c612cb99afe91db6aacb85757cfaf https://github.com/OGRECave/ogre-next/commit/2ab245a38e72cea7235d5052e1dbb318bd507b89 https://github.com/OGRECave/ogre-next/commit/51856acde12f2f5b6a3b67c62422d6c22a3e5789 https://github.com/OGRECave/ogre-next/commit/c1669907f009358d0e9eb630b537507cdac92fd2 https://github.com/OGRECave/ogre-next/commit/b79f48f70acde4c011911e805813d9ffd21cc7e9 https://github.com/OGRECave/ogre-next/commit/5da3ebca21c1faff86ea2b97ff3c5a6aefcd03d4 https://github.com/OGRECave/ogre-next/commit/91333d6031728ffd0ca9c6daa6fb519cae26874b
New data from ClangBuildAnalyzer
It shows we spend a lot of time instantiating ParamDictionaryMap. This map is used in StringInterface and Resource derives from it. As a result it ends up being used everywhere.
ParamDictionaryMap is actually used to define msDictionary which is a global static variable. It doesn't have to be declared in class StringInterface.
Additionally, moving createParamDictionary to a cpp file instead of a header should allow us to completely remove ParamDictionaryMap & msDictionary from the header definition.
OgreGpuProgram.h & OgreGpuProgramParams.h are also expensive, which are included by OgreRenderable.h and hence everywhere.
That's only needed because of _updateCustomGpuParameter. Slightly refactoring that function to use forward declarations should allow us to remove that header.
Don't know if you're aware of it, but this is a brute force tool to clean useless #include. It basically tries to build a project/solution removing headers one by one checking whether errors are raised or not.
I was aware of these tools but that one in particular looks very user friendly, thanks!
BTW I should also mention we should try Bloaty McBloatface. Example on libfmt