I think that there’s a legit rejoinder of “Why aren’t you optimizing the code to reduce compilation time, if it’s such a problem?”
For something like C++, ccache, distcc, PIMPL (to reduce use of templates, which blows up C++ compilation time), precompiled headers, make code more modular to reduce the size of the compilation unit that changes when any one change happens, break stuff into libraries, etc. Look to see whether there are things like build timestamps being inserted into headers that are producing unnecessary recompilations. clang and gcc can profile compilations to identify what’s chewing up time.
I mean, none of the optimizations I listed rely on multiple cores.
It’s true that just running parallel compilation jobs on your build machine is a simple way to speed things up, no disagreement, but it’s not like optimizing compilation time isn’t a thing outside of that.
i was thinking more about tooling, most of that stuff didn’t exist as widely as today and you couldn’t really look for it when waiting for a compile either.
Well…the in-compiler time analysis I think wasn’t as good then, though I recall doing my own ad-hoc profiling, logging time for each unit. But the refactoring stuff should be available.
I dunno how far back distcc goes.
checks git repository
The git log goes back to 2008, so almost 20 years, but it’s also talking about release 3.0 then, so there might have been time outside a VCS or with history that didn’t get imported.
In my experience, [proprietary] projects are doing well if their Makefile isn’t so broken that they have to run it twice just to make sure everything actually compiles. And you want them to actually optimize it…?!
I think that there’s a legit rejoinder of “Why aren’t you optimizing the code to reduce compilation time, if it’s such a problem?”
For something like C++, ccache, distcc, PIMPL (to reduce use of templates, which blows up C++ compilation time), precompiled headers, make code more modular to reduce the size of the compilation unit that changes when any one change happens, break stuff into libraries, etc. Look to see whether there are things like build timestamps being inserted into headers that are producing unnecessary recompilations.
clangandgcccan profile compilations to identify what’s chewing up time.that xkcd comic is coming up on 20 years old. most computers didn’t have multiple cores yet.
I mean, none of the optimizations I listed rely on multiple cores.
It’s true that just running parallel compilation jobs on your build machine is a simple way to speed things up, no disagreement, but it’s not like optimizing compilation time isn’t a thing outside of that.
i was thinking more about tooling, most of that stuff didn’t exist as widely as today and you couldn’t really look for it when waiting for a compile either.
Well…the in-compiler time analysis I think wasn’t as good then, though I recall doing my own ad-hoc profiling, logging time for each unit. But the refactoring stuff should be available.
I dunno how far back
distccgoes.checks git repository
The git log goes back to 2008, so almost 20 years, but it’s also talking about release 3.0 then, so there might have been time outside a VCS or with history that didn’t get imported.
Wikipedia says that
ccachegoes back 24 years.Taking a comic about a flimsy excuse and doing a serious analysis of a joke problem is such an xkcd thing to do.
In my experience, [proprietary] projects are doing well if their
Makefileisn’t so broken that they have to run it twice just to make sure everything actually compiles. And you want them to actually optimize it…?!