Hacker News Reader

Yes. For example our project needs about 15-20 mins for a full compile on the most expensive 15" tMBP. (It's about 10 minutes on a desktop machine due to excessive thermal throttling on the laptop but Apple kinda doesn't support those anymore).

For an Android build that project needs to build at least two architectures (x86 / armv7) to even function on emulator and target device.

CCache, ninja and all other stuff really helps, but we're still talking about minutes of compilation for a C++14 project.

I can say that in my personal experience, overly complex, difficult-to-follow code (point 4 in this hierarchy, subservient to compile time) seems to have been much more of a time-waster than build time, and certainly a greater source of bugs and inefficiency.

Build time is not necessarily wasted, either - it is time to think about what comes next.

> Is compile time a real issue these days? I worked on a code base with thousands of source files and millions (in the 100s) of lines of code 10 years ago and the build process took ~20 minutes. That's a long time, but it was 10 years ago and without a parallel build process.

Yes, I think it's still an issue. Let's say your project from 10 years ago took 20m to compile. Using a good build chain one could say, that's possible in 2m today, but this is still a lot of time.

Now, if it would take 2s - that would be a real improvement. One should not underestimate the vast benefits of a fast feedback loop.

Fast feedback can be useful, certainly. But consider that there is diminishing returns to be had. The difference between 2 minutes and 2 seconds may seem significant for this, but I have doubts. In any case it certainly isn't going to be as noticeable as a reduction from 20 minutes to 2 minutes.

The difference between 2 minutes and 2 seconds is the difference between me alt-tabbing and reading HN (and potentially getting distracted for much longer than the compile actually takes), and just staring at the IDE while the compile runs.

A huge difference in write-save-compile cycle time if it's 2 seconds or 2 minutes. According to my own like, the sweet spot is around 6 - 8 seconds, anything over that for compiling the whole project start to feel annoying.

Good thing you can script C++ with scripting languages like Lua to overcome this also though.

I would say the difference between 2 seconds and 2 minutes is significantly more noticeable than the step from 20 minutes to 2 minutes.

Apart from the fact that the factor is bigger (60 vs 10) it matters that if you go under 10s your workflow changes, as you don't have to work in "async"-mode anymore "oh, while this compiles I check this stuff in the documentation". For me who is not the best multi-tasker this is a real benefit.

I think it depends highly on what kind of developer you are and what your workflow is like. For some developers, frequent compiling is part of the development process. For others, it's something you do at the end (or after large chunks of work) to test/verify.

If you're one of those "Work on the next line, keep changing it until it compiles, then keep changing it until it runs" developers, then yea you'll want fast compiles.

If your workflow is such that you take your time, do your work once, and compile/run/test as the last step before you're ready to commit, then it doesn't really matter if your project takes 20 minutes to compile. You're only doing it once or twice a day.

When working on a new project I sometimes spend weeks coding without attempting to compile once (it usually takes a couple of day then to sake down all typos and thinkos); my boss is horrified by this but it works for me. In this scenario I care little about compiletime.

The problem is when I'm fixing bugs or adding small features to an existing codebase, especially when tests need to be added or modified. The compiletime turnarounds does kill my productivity in these cases.

It's an issue. In fact, long C++ compile times were supposedly one of the motivating factors of the Go language:

"That 2007 [Google build] took 45 minutes using a precursor distributed build system; today's version of the same program takes 27 minutes, but of course the program and its dependencies have grown in the interim ... The origin myth for Go states that it was during one of those 45 minute builds that Go was conceived."

[1] https://talks.golang.org/2012/splash.article

The project with the fastest built time I worked on was between 20-30 mins for a full build (on a dual socket desktop, significantly more on virtual machines); incremental builds were much faster, well below the minute, but touching some critical header files is always painful. This is in the order of 1 milion lines, but a lot is unfortunately in headers.

The slowest was an 8 hour overnight build for a subset of all targets. The build would also randomly fail because of race conditions in a broken build system. I don't remember the size, but probably multiple 10s of millions of lines.

Our fastest platform takes about 20 minutes to compile on a fast system (often down to about 30 seconds for incremental builds, and less if you do something fun like building in a RAM disk). On the same system, our slowest platform takes about an hour and a half (some different plugins are built, but mostly that platform just has a slow compiler). Later stages of the build have the outputs of previous stages as prerequisites.

I wouldn't put build speed above maintainability, but build speed can still be a problem for large projects.

Can you describe the build process? Building 100's of millions of lines of C++ in 20 minutes is quite a feat even today. How much parallelism and build distribution was used?

First, that's a typo. Should have been 10s not 100s. I'll correct it in the original comment.

But the result was achieved mainly by lots of compacting source code into smaller TUs, mainly, e.g. by #include-ing dozens or hundreds of .cpp files into the one that was actually sent to the compiler, and other tricks to make the number of the things the compiler had to do much smaller than a naive ("compile everything as seen in the source tree") approach would require. The original build system was not optimized in that way and took much, much longer (well over an hour, as I heard it, but that was before my time). They implemented parallel and distributed builds after I left, and as I understand it that took the whole process down to "a few minutes."

Now, it's certainly debatable whether that level of effort should be required of a build system (I lean towards "no").