The Little Things: Speeding up C++ compilation

https://codingnest.com/the-little-things-speeding-up-c-compilation/

by ingve • 6 years ago

133 82 6 years ago

adembudak• 6 years ago

Great write up. Thanks for sharing.

zabzonk2• 6 years ago

One of (many) other ways to speed up C++ (or C) builds is to use multi-processing in your make file - https://stackoverflow.com/questions/414714/compiling-with-g-... - I typically get about a 20% speed up, but obviously YMMV.

bla3• 6 years ago

This post here recommends using ninja, which does this automatically.

wetmelon• 6 years ago

Personally I like Tup, which also does this, and has no dependencies, but it has some quirks.

saagarjha6• 6 years ago

Careful, this can break certain makefiles that are not written to take this into account.

zabzonk2• 6 years ago

Perhaps post a link to this problem?

saagarjha6• 6 years ago

Remember that std::vector consists of three pointers to a chunk of dynamically allocated memory.

Note that this is not required, and most std::string implementations inline small strings anyways.

nikki932• 6 years ago

Was your `std::string` SBO comment meant to relate to the `std::vector` quote? `std::vector` can't use SBO bc. `std::swap` on `std::vector`s can't invalidate pointers to elements.

saagarjha6• 6 years ago

I swapped std::string and std::vector when writing that comment :/ But still, there's no need for a vector to necessarily keep three pointers, it could use a pointer and two sizes for example.

gjvc• 6 years ago

This is an excellent and thorough review of the details.

An almost-should-be-mandatory tool on projects of any decent size is https://ccache.dev/

modeless4• 6 years ago

I wish someone would pick up the zapcc project. Compilers do an insane amount of duplicated and redundant work and there's tremendous potential for speeding up C++ builds if you are willing to rethink how the compiler works a little bit. https://github.com/yrnkrn/zapcc

wheybags3• 6 years ago

I work on the video game factorio, which is a c++ project. On a 9900k a rebuild takes about a minute, so it's pretty sizeable but not something ridiculous like oracle db or unreal engine. I tried using zapcc on it, and it was a complete failure. I don't have measurements to hand, but iirc it was actually slower than stock clang. I tested it on a threadripper 2950x with 64gb of ram, running Debian.

modeless4• 6 years ago

I've had good results on some of my own projects. The current implementation certainly has limitations, but it's really early and the potential is huge. For example, because it can cache at a sub-compilation-unit granularity it can make rebuilds of a single file faster, which no distributed build tool or cache can do.

MontagFTB• 6 years ago

Thank you for Factorio!

jiggawatts2• 6 years ago

I just installed the game again to play the v1.0 release.

It looks and sounds very good! Congratulations on making it to the release milestone after many years of hard work.

As a developer, I must say that I'm deeply impressed by the simulation complexity and incredible scalability.

I keep telling people that Factorio is the most complex train simulator game that I've ever played. But it isn't a train simulator. It's a factory game. The trains are optional.

That's crazy to me, that a subset of a game can be more complex than entire games that "specialise" in the topic.

stephc_int137• 6 years ago

Have you tried switching to a unity build? Or removing templates?

jnxx3• 6 years ago

How does ccache compare to it?

https://ccache.dev/

chubot• 6 years ago

Is this like llbuild?

https://www.youtube.com/watch?v=b_T-eCToX1I

https://github.com/apple/swift-llbuild

I remember watching the talk awhile ago, but haven't kept up with its progress. It's about using LLVM as a library to eliminate duplicate work, as far as I remember.

I think it was for C++ as well as Swift.

usrnm• 6 years ago

Compilers do an insane amount of duplicated and redundant work

This is one of the problems that should be solved by modules in the near future.

modeless4• 6 years ago

I hope so but last time I looked it seemed like the preliminary implementations didn't improve build times much in practice.

jnxx3• 6 years ago

One reason why this might not be so simple is that what is often measured as a potential for speed improvement is I/O, as in "lines of code a compiler needs to read to process a translation unit". However what happens is that C++ compilers are usually CPU-bound, not I/O bound. What happens also is that C++, very differently from idiomatic C, Pascal, Modula, and their successors, has no clear separation between declaration and use of an interface, as not functions, but classes form the main interface, and what defines a class is the signature of its member functions and its members, and to know the size of the class, the size of its members need to be known, which has the consequence that the C++ compiler needs to read recursively everything which the class is defined with. This is a big difference to modula etc. Also, of course the reading of data can be cached, but the question is how much the expansion of the read text can be cached - for example some will have different semantics if the DEBUG macro is set, or some WIN_xyz macro. As far as I understand, compilers supporting C++ modules will only cache the latest expansion.

Also, the build system with modules is likely to become more complex, with additional dependencies. I do not know whether this is still actual in every aspect (it could be that what is allowed to go into a module header has been narrowed down a bit), but this post : https://vector-of-bool.github.io/2019/01/27/modules-doa.html explains at least some of the topics involved, and not all of them are trivial.

stephc_int137• 6 years ago

From my experience, unity builds (single compilation unit with #include of all source files into a single main file) and use of orthodox C++ (avoidance of templates and fancy features) is giving good results.

ladberg• 6 years ago

That sounds like it breaks all incremental builds (correct me if I'm wrong) for relatively little benefit (skipping linking? less header parsing?). Are there scenarios where unity builds are faster than incremental builds? Or is the intended use-case only for from-scratch builds?

keldaris4• 6 years ago

In my experience, you can just do full from-scratch builds in under 10 seconds for any sanely sized codebase (say, under 1M LoC conservatively). This obviously assumes the "orthodox C++" part, so YMMV wildly depending on how far you stray from that. I usually have compile times under 0.5s for all personal projects that don't use CUDA, but I basically write C with a bit of function/operator overloading, absolutely no STL or templates at all. Consequently, I have no use for incremental (or parallel, for that matter) builds whatsoever.

stephc_int137• 6 years ago

Yes, absolutely, that's the trick with unity builds. It is supposed to be slower because you're asking the compiler to rebuild everything from scratch every time.

But the simplicity of the single compilation unit leads to very sizeable gains.

I plan to write an article on this very subject and post a few benchmarks.

https://en.wikipedia.org/wiki/Unity_build

adrian17• 6 years ago

There doesn't need to be exactly one unity translation unit. In Firefox, the build system groups source files by component, and then into "unity" batches containing 5-20 source files each.

If a build spends a lot of time processing code in headers, and source files in the same component are likely to include very similar sets of headers, this kind of configuration gives decent benefits, while not making incremental compilation much more expensive (and possibly cheaper, if you edited a header affecting many files in a single component).

barumi2• 6 years ago

It's reasonable to assume that compilation times can go down if you decide to forego compile-time features (i.e., templates).

However, C++'s standard library is a productivity blessing. I'm not convinced of the advantage of replacing it with ad-hoc components that may or may not be buggy just because you want to shave off a few seconds of each build.

More often than not, all you have to do to lower a double-digit percentage of your compilation time is to modularized your project, and follow basic principles like not have includes in your interface headers. This alone, along with PImpl, does far more for your compilation time than well-meaning but poorly thought-out tradeoff decisions like not using the STL.

stephc_int137• 6 years ago

Using the STL is a non-issue for me as it is almost never used in the video games industry, mostly for performance reasons.

In my opinion the STL is still a big, bloated, unreadable piece of code with a few badly implemented good ideas (containers)

You should read this article: https://zeux.io/2019/01/17/is-c-fast/

keldaris4• 6 years ago

There is no way to use the STL and other template code and still have reasonably sized projects do full builds in seconds. That's just an empirical fact. The only way to get C-like compile times is to essentially write C, with minor additions.

If you genuinely regard the standard library as a productivity blessing I'm sure this looks like an unreasonable tradeoff. I would be very surprised to see someone advocate writing "Orthodox C++" solely for the compile times. Most of us who write code like this do so because we don't find value in the STL and regard templates as an extremely poor tool for their ostensible purpose. The compile times are just a bonus, albeit a very pleasant one.

In truth, the divide isn't between people who prioritize compile times over any other consideration and people who don't. It's between people who see most of the language features of C++ as valuable and people who see them as mostly unhelpful. Personally, I like operator overloading for math and SIMD types, function overloading for less verbosity, namespaces and a bit of constexpr for convenience. The rest I'm quite happy to do without, so there isn't much of a tradeoff to make.

bregma• 6 years ago

"Orthodox C++" without templates, language features, or the standard library is also known as "C".

I'd go one step further. Skip the compiler and just write in assembly. Your builds will be lightning fast especially if you use one single source file with no macros and static linking. You'll never ship, but you'll never ship really fast.

stephc_int137• 6 years ago

You'd be surprised by how many "C++" projects are in fact mostly C with a few C++ features in the videogames industry.

keldaris4• 6 years ago

Except people do in fact ship large C projects all the time. The productivity gain associated with moving from assembly to C is undisputed and vastly exceeds any alleged productivity gain associated with moving from C to modern C++. Pretending otherwise is just facetious.

tekknolagi• 6 years ago

How does the <algorithm> header compare in that list? That's the one I always try and avoid in my projects.

jart• 6 years ago

What I've found wreaks the most havoc on build times is having too many -iquote and -isystem flags. Last time I profiled TensorFlow compiles using strace, about half the gcc wall time was spent inside all the stat() system calls those flags generate.

gumby• 6 years ago

Modules are supposed to make much of this now quite useful info irrelevant.

Unfortunately modules are several years in the future, both due to lack of implementations yet and the fact that few projects are being written in C++20 yet. I also harbour a suspicion that tricks like these will still be useful with modules.

tomovo• 6 years ago

Last time I checked somebody working on modules said something along the lines of "don't expect modules to speed things up". The goals were different, apparently (stop #defines from leaking everywhere, large-project management, libraries). Has this changed, are there any benchmarks available?

zarkov99• 6 years ago

If its true that speeding up compilation was not a goal then the committee is out of its mind. Speeding up compilation would have more impact on productivity and the environment than almost anything else that could be done with the language.

will42742• 6 years ago

Modules contain an optimization (less include leaking) and a pessimization (more serialized build graph). Only the former applies to CPU time, so modules should lead to less cpu time, but it's unclear exactly how that translates to wall time.

mhh__• 6 years ago

I still haven't seen a module in the wild yet, they should've been standardized 20 years ago now (D has had modules from day 1, and there are more people on the C++ committee than working on D at all) . I hope they get some traction but I just can't see it helping for all but the newest codebases.

josefx• 6 years ago

As far as I understand the issue is basically in the hands of the compiler vendors. They need to have a solution that they can agree on before the c++ committee finalizes it.

m0zg• 6 years ago

Just use a build system in which reliable incremental builds are possible and are the default. Your compilation will take seconds most of the time.

jeffbee• 6 years ago

Builds are just like any other software: if it takes too long, profile it. Use bazel build --profile or whatever equivalent your build system offers.

cgrealy2• 6 years ago

On thing about forward declarations: they violate DRY.

Now, most of the time, the trade off of repeating

  class Thing;

is more than offset by faster build times.

But if

  class Thing;

is actually

  namespace Bob
  {
    namespace Dave
    {
      template <typename T>
      class ThingTrait;

      template <typename T>
      class Thing : BaseClass<T, allocator<T>, trait<ThingTrait<T> >;
    }
  }

you really want to put that in it's own header, typically "Thing_fwd.h"

(apologies for any syntax errors, been a while since I've written C++)

asdfasgasdgasdg3• 6 years ago

You're either gonna write

    #include "thing.h"

    class Thing;

Either way, as a practical matter, you're saying, "There's something called Thing I'm going to use." C++ forces you to say that before use in each translation unit. It's not really "repeating" yourself to write it, since you haven't "said" it yet in this TU.

cgrealy2• 6 years ago

You are repeating yourself if you write

  class Thing;

in every file that uses a Thing. And as I said, that's generally fine.

The issue becomes when the declaration of Thing includes namespaces, template params, etc. Rewriting that is tedious and error prone.

Look at something like std::string. That's actually

  namespace std {
  template< class T > struct allocator;
  template<class charT> struct char_traits;
  template<> struct char_traits<char>;
  template<class CharT, class Traits = char_traits<CharT>,
           class Allocator = allocator<CharT>>
    class basic_string;
  using string    = basic_string<char>;
  }

No-one is forward declaring that.

steerablesafe• 6 years ago

I prefer _fwd headers for a different reason: it's easier to modify without breaking dependencies.

If you change Thing to an alias to a class template specialization then all of the "class Thing;" forward declarations break.

ephimetheus2• 6 years ago

Another tip to keep compilation fast: don’t use Eigen. Non-trivial usage absolutely obliterates compile times and blows up the memory consumption by an insane amount.

barumi2• 6 years ago

Eigen is an absurdly template-intensive library, and people use it because so far there is nothing better or even remotely comparable to it.

If you use Eigen but somehow feel that compilation time is your focus instead of actually doing linear algebra or solving systems of linear equations then you have a few best practices that you can follow and techniques at your disposal to lower compilation times.

ephimetheus2• 6 years ago

Such as? (genuinely curious) We've been trying hard to get memory consumption down because we get OOMs in our CI frequently. (Our largest compilation unit compiles for 3 minutes and peaks at just under 6GB memory)

happyweasel• 6 years ago

Hmm... What about the pImpl Idiom? That should also help (and also brings in it's own costs).

flohofwoe• 6 years ago

Bruce Dawson's Chromium build time investigation is very enlightening:

https://randomascii.wordpress.com/2020/03/30/big-project-bui...

The main takeaway:

That is, the main source files represent just 0.32% of the lines of code being processed.

Chromium itself has about 12 million lines of code, but the compiler needs to process 3.6 billion lines of code because it needs to parse the same headers over and over again.

secondcoming3• 6 years ago

There's a lot of money to be made by someone who write a tool that takes in a C++ codebase and suggests all the improvements that can be made to speed the build up.

grandinj2• 6 years ago

If you can get it to work (not guaranteed) icecream can make a very large difference.

kevincox• 6 years ago

This appears to be referring to a distcc derivative https://github.com/icecc/icecream

Note that discc doesn't really solve the header problem, it just throws more compute at it.

grandinj2• 6 years ago

Yup, some people use spare machines lying around the office, some people buy a big-ass server that can be shared between the developers, some people (like me) buy a bunch of used desktop-class quad-core machines and run a little build cluster.

Very useful if you are working on very large codebases (I hack on LibreOffice, 10M LOC, from time to time).

The Little Things: Speeding up C++ compilation

Related Stories