5 ms·

I emphatically disagree -- compile times are definitely on my short-list of worst things about C++. Long compile times disrupt flow, and it requires great ongoi

by jasone 5y ago

I emphatically disagree -- compile times are definitely on my short-list of worst things about C++. Long compile times disrupt flow, and it requires great ongoing mental effort to work around slow compilation. Here's a poignant anecdote. At one point while working on HHVM at Facebook I finally snapped, spent 2-3 days doing nothing but optimizing the build system to speed up trivial incremental compilation (e.g. a whitespace change). My efforts resulted in... 24 seconds best case. I spent years on that project pipelining my coding, that is, making a small change, asynchronously launching a build, fixing issues from the previous build attempt, ad nauseam, and the pipelining was oftentimes 3+ deep due to latency. That cognitive load severely impacted productivity. That said, I agree that C++ has a lot of other terrible problems too!

mpyne 5y ago
> Long compile times disrupt flow, and it requires great ongoing mental effort to work around slow compilation. We once reimplemented automake in KDE land (into a tool 'unsermake' by Stephan Kulow), for a few reasons but foremost among them was that it reduced compile times, sometimes drastically.
jcelerier 5y ago
24 seconds is awful ? I have a 500kloc codebase which uses boost, Qt, and templates & modern features used very liberally and incremental compilation is ~1 second
- tom_ 5y ago
  Is it open source, and can you post a link? I have never seen this type of project even link in 1 second.
  - jcelerier 5y ago
    sure, it's https://ossia.io https://ossia.io. Here's a video of my edit-compile-run cycle: https://streamable.com/az397y https://streamable.com/az397y To get to something that fast for incremental builds of course requires some tweaks from the buildsystem defaults: - clang instead of gcc (I use clang on mac, windows, linux) - ninja instead of make - -gsplit-dwarf for debug info - mold instead of ld (I used lld before which was already nice but mold is bewildering) - PCH (very easy with cmake thankfully !) - split in shared libraries of adequate granularity, e.g. the software is split in ~40 plug-ins (although with mold I'm not sure this is even relevant anymore, the complete link step if I don't use shared libraries is not that slow). I've encoded most of these in my cmake toolchain-generator, cninja: https://github.com/jcelerier/cninja/ https://github.com/jcelerier/cninja/ To give some reference, my hardware is a 8c/16t intel 6900k. Edit: I did a complete build with everything statically linked instead of through shared libraries. To give a reference: lld (which is already fast compared to GNU ld and gold) links the entire software in 0.47 seconds ; mold links it in 0.3
    - nottorp 5y ago
      Is there anything left out of the "standard" setup? :) > split in shared libraries of adequate granularity, e.g. the software is split in ~40 plug-ins So you had to alter your project structure to improve build times?
      - jcelerier 5y ago
        > Is there anything left out of the "standard" setup? :) I don't believe in accepting things just because some engineer choose a default under some deadline 25 years ago > So you had to alter your project structure to improve build times? no, the software was designed as-is from the very beginning (and it's an architecture I'd recommend for any software which is supposed to be extensible from its very inception, it worked out very well)
        nottorp 5y ago
        > I don't believe in accepting things just because some engineer choose a default under some deadline 25 years ago That's not the point. The point is the "standard" is suboptimal enough that you basically have to change it. Don't think that applies to much of the competition (with the exception of Java that isn't really competition?).
        jcelerier 5y ago
        > The point is the "standard" is suboptimal enough that you basically have to change it. but there's no standard, just CMake defaults that I change ? It's not more standard to call /usr/bin/clang++ than /usr/bin/g++ (and if I was running freebsd instead of linux, as far as I know that's what would happen by default) ; likewise, other build systems like Meson use ninja by default (and that does not make ninja any more of a standard than make is when using cmake under GNU/Linux). Those are just tools in a toolbox.
omegalulw 5y ago
What build system do you use at Facebook? Changing a whitespace in a .cc should always cause just that for to be compiled. Changing whitespace in a header is trickier and smart build systems can inner that you didn't change code as compared to whatever was cached.
- cma 5y ago
  Many setups combine multiple cpps into one, per module. I think for making debug builds faster and because the linker is the slowest part due to not being parallelizable until recently.

by jasone 5y ago

mpyne 5y ago

> Long compile times disrupt flow, and it requires great ongoing mental effort to work around slow compilation. We once reimplemented automake in KDE land (into a tool 'unsermake' by Stephan Kulow), for a few reasons but foremost among them was that it reduced compile times, sometimes drastically.

jcelerier 5y ago

24 seconds is awful ? I have a 500kloc codebase which uses boost, Qt, and templates & modern features used very liberally and incremental compilation is ~1 second

tom_ 5y ago
Is it open source, and can you post a link? I have never seen this type of project even link in 1 second.
- jcelerier 5y ago
  sure, it's https://ossia.io https://ossia.io. Here's a video of my edit-compile-run cycle: https://streamable.com/az397y https://streamable.com/az397y To get to something that fast for incremental builds of course requires some tweaks from the buildsystem defaults: - clang instead of gcc (I use clang on mac, windows, linux) - ninja instead of make - -gsplit-dwarf for debug info - mold instead of ld (I used lld before which was already nice but mold is bewildering) - PCH (very easy with cmake thankfully !) - split in shared libraries of adequate granularity, e.g. the software is split in ~40 plug-ins (although with mold I'm not sure this is even relevant anymore, the complete link step if I don't use shared libraries is not that slow). I've encoded most of these in my cmake toolchain-generator, cninja: https://github.com/jcelerier/cninja/ https://github.com/jcelerier/cninja/ To give some reference, my hardware is a 8c/16t intel 6900k. Edit: I did a complete build with everything statically linked instead of through shared libraries. To give a reference: lld (which is already fast compared to GNU ld and gold) links the entire software in 0.47 seconds ; mold links it in 0.3
  - nottorp 5y ago
    Is there anything left out of the "standard" setup? :) > split in shared libraries of adequate granularity, e.g. the software is split in ~40 plug-ins So you had to alter your project structure to improve build times?
    - jcelerier 5y ago
      > Is there anything left out of the "standard" setup? :) I don't believe in accepting things just because some engineer choose a default under some deadline 25 years ago > So you had to alter your project structure to improve build times? no, the software was designed as-is from the very beginning (and it's an architecture I'd recommend for any software which is supposed to be extensible from its very inception, it worked out very well)
      - nottorp 5y ago
        > I don't believe in accepting things just because some engineer choose a default under some deadline 25 years ago That's not the point. The point is the "standard" is suboptimal enough that you basically have to change it. Don't think that applies to much of the competition (with the exception of Java that isn't really competition?).
        jcelerier 5y ago
        > The point is the "standard" is suboptimal enough that you basically have to change it. but there's no standard, just CMake defaults that I change ? It's not more standard to call /usr/bin/clang++ than /usr/bin/g++ (and if I was running freebsd instead of linux, as far as I know that's what would happen by default) ; likewise, other build systems like Meson use ninja by default (and that does not make ninja any more of a standard than make is when using cmake under GNU/Linux). Those are just tools in a toolbox.

omegalulw 5y ago

What build system do you use at Facebook? Changing a whitespace in a .cc should always cause just that for to be compiled. Changing whitespace in a header is trickier and smart build systems can inner that you didn't change code as compared to whatever was cached.

cma 5y ago
Many setups combine multiple cpps into one, per module. I think for making debug builds faster and because the linker is the slowest part due to not being parallelizable until recently.