3 ms·

gcc at -O0 -g has always been decent enough for me, and I never saw any significant difference with clang (either in the past when gcc -O0 used to be /slighly/

gcc at -O0 -g has always been decent enough for me, and I never saw any significant difference with clang (either in the past when gcc -O0 used to be /slighly/ slower, or now). Things change with -Ox, but then again, who really cares? Generating optimized binaries is not something I do routinely, except when tuning for performance. When I'm generating a binary for release, I couldn't care less if the project actually took 2x times to compile. In fact, to use feedback-directed optimization (which on some projects may make a marked difference, usually larger then the generated binary at O3 between gcc/clang), you actually have to build it twice, and _very_ few people actually bother. clang used to be much faster at building, but then again the binary was never equally on-par performance wise. As clang is getting better at optimizing, the compilation times are getting more and more similar. This is again, all hardly surprising for me. I _have_ worked on projects using C++ where build times where incredibly slow. They all shared the common attribute of #include <megaheader_with_all_class_definitions> and "using namespace library". For other projects, as long as rebuilding an object takes 2 seconds or 10, does it really make a difference? In those cases, linking actually takes disproportionately longer, to the point that compilation times are insignificant. It's a genuine question.

cLeEOGPw 13y ago
2x release build compile time might not be a huge deal to you personally, but over thousands of builds that are happening every day, a 2x decrease in time would mean a lot of saved processing power and electricity. Speed is always important in tools like compiler, so there is never a legitimate excuse for it to be slower than it could be.
- tenfingers 13y ago
  Cannot deny that. And it's undoubtedly helpful also for continuous integration. Poor performance is never a good excuse. But my perception reading these articles is that the tone is different. There's seems to be a "huge problem with compilation speed in c++", that's also "a detrimental factor to using c++ itself" that I _never_ really experienced, except, like I said, in badly-organized projects. It always felt to me, by programming, that writing and debugging were _always_ the problem, never compilation itself. By reading these articles, it feels like I'm either too slow, or there is some magic that I would need to be doing to use the compiler 20x more than what I'm doing now.
  - rwbt 13y ago
    Usually, when compiling projects that use Boost libraries which are sometimes very template heavy, the compile times are very long in my experience. Especially, something like the Boost Spirit.
Narishma 13y ago
Your projects aren't video games, are they? It's not very feasible to debug games at -O0, unless they're very small. And I don't how if profile guided optimization is feasible either.
- tenfingers 13y ago
  I've worked in large projects where the build of the entire project (c++ of course) took around 75 minutes, and performance was important (real time visualization of volumetric data). It happened to me _very_ rarely to change a global header that would cause a massive rebuild. Most of the time I would rebuild just the current object I was working on, taking anywhere from 10 to 60 seconds. Yet, linking took massively longer (around 4 minutes as I recall).
- endianswap 13y ago
  I've worked on several AAA games and have never had a problem running/testing/debugging with optimizations off. There's a framerate hit, of course, but I've never had a problem debugging because of it. Trying to debug with optimizations on is usually a bigger time sink than just debugging at 20fps. When I'm dealing with gameplay code and not engine code I'll normally just build with all optimizations on except -O0 the gameplay modules so I get full framerate and perfect debugging of the code I'm interested in. But usually that's not necessary (except it gives me faster load/restart times.)

cLeEOGPw 13y ago

2x release build compile time might not be a huge deal to you personally, but over thousands of builds that are happening every day, a 2x decrease in time would mean a lot of saved processing power and electricity. Speed is always important in tools like compiler, so there is never a legitimate excuse for it to be slower than it could be.

tenfingers 13y ago
Cannot deny that. And it's undoubtedly helpful also for continuous integration. Poor performance is never a good excuse. But my perception reading these articles is that the tone is different. There's seems to be a "huge problem with compilation speed in c++", that's also "a detrimental factor to using c++ itself" that I _never_ really experienced, except, like I said, in badly-organized projects. It always felt to me, by programming, that writing and debugging were _always_ the problem, never compilation itself. By reading these articles, it feels like I'm either too slow, or there is some magic that I would need to be doing to use the compiler 20x more than what I'm doing now.
- rwbt 13y ago
  Usually, when compiling projects that use Boost libraries which are sometimes very template heavy, the compile times are very long in my experience. Especially, something like the Boost Spirit.

Narishma 13y ago

Your projects aren't video games, are they? It's not very feasible to debug games at -O0, unless they're very small. And I don't how if profile guided optimization is feasible either.

tenfingers 13y ago
I've worked in large projects where the build of the entire project (c++ of course) took around 75 minutes, and performance was important (real time visualization of volumetric data). It happened to me _very_ rarely to change a global header that would cause a massive rebuild. Most of the time I would rebuild just the current object I was working on, taking anywhere from 10 to 60 seconds. Yet, linking took massively longer (around 4 minutes as I recall).
endianswap 13y ago
I've worked on several AAA games and have never had a problem running/testing/debugging with optimizations off. There's a framerate hit, of course, but I've never had a problem debugging because of it. Trying to debug with optimizations on is usually a bigger time sink than just debugging at 20fps. When I'm dealing with gameplay code and not engine code I'll normally just build with all optimizations on except -O0 the gameplay modules so I get full framerate and perfect debugging of the code I'm interested in. But usually that's not necessary (except it gives me faster load/restart times.)