> 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.
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.