Hacker News new | ask | show | jobs
by cjensen 2723 days ago
Just to address part of your concern: Traditionally disk speed makes very little difference to compile times for real world C/C++ projects. This is because real world projects have many files, and each one can be compiled in parallel. Once you spawn sufficient compilers in parallel, the CPU becomes the bottleneck, not the disk. (I.e. when a compilation asks for I/O, it then yields the CPU to other compilers which have CPU work to do)

Note that Visual Studio, for example, does a poor job of this because it only spawns one compilation per CPU thread. This results in individual threads being idle more than they ought to be.

3 comments

I guess it depends on how you define "very little", and what system includes you have.

I've just tested one of my ~300 KLOC C++ projects, broken into 479 .cpp files and 583 .h files.

Using Linux (GCC) after dropping the disk cache, on a 5400 RPM HD, the full build on 14 threads took: 78 seconds.

On a fast SSD (same machine, after dropping caches again) it took 61 seconds.

Linking was ~7 seconds faster on the SSD, so arguably you could say that actual compilation wasn't the same ratio as fast, but overall build time is most definitely faster.

Source was on the same drive as the build target directory.

At a previous company I worked at, we got SSDs to speed up compilation (and it did).

This very much depends upon the project. Have you seen the size of C++ object files with -g3 and lots of template usage? It can swallow tens of gigabytes of disc space only to have the linker elide most of it and give you a library or executable a few megabytes in size. Compared with the size of the inputs, the output is causing a vastly disproportionate amount of disc I/O, and this can end up being limiting, both during compilation and in particular during linking.
Absolutely not true. The problem is not the compilation of one single file, but that every one of these single files pulls in large amounts of headers, distributed over various libraries (e. g. Qt/Boost/STL), all of which won't fit into the disk cache.

If it doesn't make a difference, all that means is that your project is small, or doesn't have too many dependencies. Good for you. But that's not the reality for all projects.

My projects take 10 minutes to build on a modern system, which is plenty complicated enough. Don't appreciate the "good for you" flippancy.