5 ms·

Is compile time a real issue these days? I worked on a code base with thousands of source files and millions (in the 10s [corrected from 100s]) of lines of code

by sidlls 9y ago

Is compile time a real issue these days? I worked on a code base with thousands of source files and millions (in the 10s [corrected from 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. The code leveraged templates and other features of C++ that tend to lengthen compile times, too. Sure, we should strive for minimal compile time (it's expensive idle-time for a developer) but I'm not convinced it's worth allocating developer effort to except in egregious cases. Quality development that doesn't explicitly carve out time to focus on compile time should produce code that compiles in a reasonable time anyway. In general (and for the majority of cases by a significant margin) I agree that maintainability should overrule run time performance. However as always there are tradeoffs to consider. If one is only going to use a program briefly or a small number of times maintainability becomes a lower priority.

izacus 9y ago
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.
zeptomu 9y ago
> 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.
- sidlls 9y ago
  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.
  - plorkyeran 9y ago
    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.
  - inDigiNeous 9y ago
    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.
  - zeptomu 9y ago
    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.
    - ryandrake 9y ago
      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.
mannykannot 9y ago
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.
dwtdfw 9y ago
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 https://talks.golang.org/2012/splash.article
Game_Ender 9y ago
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?
- sidlls 9y ago
  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").
khedoros1 9y ago
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.
gpderetta 9y ago
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.

by sidlls 9y ago

izacus 9y ago

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.

zeptomu 9y ago

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

sidlls 9y ago
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.
- plorkyeran 9y ago
  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.
- inDigiNeous 9y ago
  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.
- zeptomu 9y ago
  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.
  - ryandrake 9y ago
    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.

mannykannot 9y ago

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.

dwtdfw 9y ago

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 https://talks.golang.org/2012/splash.article

Game_Ender 9y ago

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?

sidlls 9y ago
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").

khedoros1 9y ago

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.

gpderetta 9y ago

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.