3 ms·
I have worked for game companies making large console games both with the STL and without. One thing I noticed about STL is that it really bloats the build tim
by uglycoyote 11y ago
I have worked for game companies making large console games both with the STL and without. One thing I noticed about STL is that it really bloats the build times because the STL headers are so massive. I did some analysis of the preprocessor output one time and found that just including a couple of headers like vector.h and string.h would increase the size of the preprocessor output by 80000 to 100000 lines, even for a cop file that is otherwise trivially small. Typically almost every cpp file in the codebase would either directly use STL headers or bring them in as dependencies, and so in a codebase of a few thousand files you are talking about hundreds of millions of extra lines of code that the compiler has to churn through. This amounted to each cpp file talking several seconds to compile and the entire codebase taking most of an hour to rebuild. People would not have been able to survive that without using Incredibuild to farm off compilation to other machines. The company I currently work at does not use STL and so largely avoids this problem. I an curious to what extent EASTL has this problem or avoids it.
- maximilianburke 11y agoEASTL still has this problem. It's worse on Windows where the prerequisite system header (ie: yvals.h, etc.) can bring in a ton of bloat. Until modules are a reliable thing and we can take advantage of them in a reasonable cross platform way it will still remain a problem.
- egoots 11y agoIsn't part of this addressed by taking advantage of the new C++ 11 extern template feature? http://www.stroustrup.com/C++11FAQ.html#extern-templates http://www.stroustrup.com/C++11FAQ.html#extern-templates
- thinkdoge 11y agoThe real solution is 'import' but we probably won't see that in ++17