
C++ Compilation Speed - fogus
http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html
======
atlei
My guess for most slow compiles (yes, pulled out of my ...hat):

1\. Templates

2\. No pre-compiled headers

3\. Bad header-organization

We have a reasonable sized desktop application 5 mb (release) / 19 mb (debug)
that fully rebuilds in 10 s / 12 s (incremental < 2 s usually).

Yes, we have optimized using a RAM disk etc, but the main reason for the speed
is No Templates and combining precompiled headers with efficient header-
organization.

Some interesting links:

\- [http://gamesfromwithin.com/physical-structure-and-c-
part-2-b...](http://gamesfromwithin.com/physical-structure-and-c-part-2-build-
times)

\-
[http://developers.sun.com/solaris/articles/CC_perf/content.h...](http://developers.sun.com/solaris/articles/CC_perf/content.html)

~~~
shin_lao
Except that templates give you runtime speed and our customers care about
runtime speed, not compilation speed.

~~~
xyzzyz
What kind of speed increase are you talking about? Your comment's logic seems
to suggest that, for instance, C (a language without templates) is inherently
slower than C++, which is not the case. Can you back your statements up with
evidence?

~~~
sreque
Speed increases like those explained in
[http://www.tilander.org/aurora/2007/12/comparing-stdsort-
and...](http://www.tilander.org/aurora/2007/12/comparing-stdsort-and-
qsort.html), which compares qsort to std::sort.

Because templates are basically automated code copy-paste, the compiler can
more easily inline at compile-time. Unfortunately, it also translates to lots
more compiled code, which means slower compile times and fatter binaries.
Still, writing something like the STL library in C with the same performance
characteristics would be much more difficult, if not impossible.

I'm not a C++ expert, but that's my understanding of things, at least.

~~~
pborges
If you are worried about the performance hit caused by function calling
through a function pointer you might want to give a look at
<http://sglib.sourceforge.net/>.

------
bh42
I trust the people who care already know about distcc on Linux and
Incredibuild on Windows, but I thought I'd mention them just in case.

~~~
randombit
Don't forget ccache - storing the cache on a fast disk, it can easily speed up
a build by 10x.

------
aycangulez
I still remember the day I compiled an example program that came with
Borland's Turbo Pascal and Turbo C++ compilers. This program was designed to
showcase Borland's text-mode user interface library called Turbo Vision, and
apart from the programming language used, it ran exactly the same.

Turbo Pascal took just a few seconds to compile the example (no surprises
there), but Turbo C++ took several minutes. This was back in the 90's. It
seems nothing has changed since then. Sad.

~~~
albertzeyer
That's because those languages haven't changed or only been extended.

------
modeless
Had nobody ever attempted to fix these problems in a non-backwards-compatible
way? I'm imagining a new "almost-c++" that ditches the preprocessor for
something better and makes a few other changes with the goal of vastly
improved compile times. Then it should be possible to produce a GCC or Clang++
plugin that translates from C++ to "almost-C++" automatically, making it
trivial to switch.

~~~
Abscissa
Yes, they have. It's called D: <http://www.digitalmars.com/d>

It doesn't have an automatic translator, but it's design does follow a rule of
"If a piece of C code is dropped into a D compiler, either it compiles with
the same semantics, or it doesn't compile."

BTW, Someone needs to fix the CSS for this text-entry box. Someone set the
text color to black, but forgot to set the background color too. So on my
light-on-dark system, I get Invisible-text-syndrome and have to edit in
notepad and copy-paste into the text-box. Wheee!

~~~
janzer
Also note that the author of the article is also the author of D.

------
smcl
I sat throught he pain of configuring\testing boost on a set (non GNU\GCC) dev
tools for embedded platform and the build times were painfully slow - around
15 minutes was common even for reasonable sized tests. A fresh build of the
boost libraries themselves - hours.

~~~
gryan
It's unfortunate that Boost is an all-or-nothing set of libraries, and the
meta-programming in there can be brutal to compile, so for that kind of
platform you'd really need to weight the pros and cons of what you're using
out of Boost vs. compile times.

However, building the library set and examples and tests is a one-time cost
for the non-header-only libraries. And you don't need to compile the examples
or the tests. Or the various debug-release combinations.

Plus, why wouldn't you cross-compile, anyway? I do lots of embedded sensor
work and I wouldn't think of compiling anything directly on the hardware
itself.

~~~
smcl
This was cross-compiled. We had just implemented the full (as opposed to
abridged) C++ libraries so obviously we decided to make sure that our
customers could use them fully, however given that this was new support there
was a distinct lack of test cases. Someone suggested that Boost exercised this
functionality pretty well (some customers previously complained that they had
been prevented from using boost before due to our only supporting the abridged
libraries so this was actually a good idea), someone decided that I should be
in charge of this.

What it amounted to was debugging horrible compiler crashes, broken library
behaviour and spending a long time deciphering huge template names. This
caused me to hate C++ more than you can ever imagine. I swear whoever decided
to stitch templates together in the way Boost does has never had to debug a
development compiler, this broke almost every part of the toolchain.

Ugh.

------
tomjen3
This to me is one of the best arguments for a new language that takes over the
traditional role of C++ - writting programs in it is just too slow.

I can't even imagine what it would be like on a 100hz computer.

~~~
jsyedidia
D and Go are the two languages poised to take over the roles of C and C++.
They both have very fast compilers and numerous other advantages compared with
C and/or C++. I've looked at both of them quite carefully, and decided that D
works better for me (an important factor for me though was that D2 recently
stabilized with the publication a couple months ago of Andrei Alexandrescu's
excellent new book "The D programming language"). There's an interesting
recent thread debating the merits of the two languages at the golang-nuts
mailing list.

~~~
rubashov
> languages poised to take over the roles of C and C++

D has been around for ages, during which time C++ usage has grown quite a lot,
essentially at the expense of C and assembly.

First of all, I don't get the sense people are actually casting about for a
C++ replacement. Secondly, garbage collection makes D a non-starter in
probably over half the areas C++ is used.

~~~
jsyedidia
Given that Andrei Alexandrescu, who is one of the best-known C++ programmers
in the world, co-designed (with Walter Bright) the new version of D, I would
say that there are at least some C++ programmers looking for a better
language. I think there's also a lot of C programmers looking for a better
language but unwilling to deal with C++ (I'm in that category myself). Garbage
collection in D is optional.

~~~
rubashov
I'm not poo-pooing D at all, it just it seems to compete more with Java/C#
than C++.

C++ is now really for closer to the metal, where garbage collection is truly a
non-starter and nobody cares that std::string is awkward because they don't
use it.

~~~
eru
Can you explain why, if garbage collection is a non-starter, _optional_
garbage collection should have any negative impact?

~~~
coffeeaddicted
I would say it depends on what the libraries do expect, especially the D
standard libraries. If those work with and without garbage collection it
probably doesn't matter so much. If those expect garbage collection then I
suppose D2.0 will have a hard(er) time luring that many c++ guys over.

Does anyone already know how the new standard libraries which they wrote do
work?

~~~
jsyedidia
Andrei Alexandrescu addresses the issue of programming in D without garbage
collection in this interview from yesterday:
<http://www.informit.com/articles/article.aspx?p=1622265>

Notice in particular that he says "Furthermore, you can use malloc() and
free(), along with the rest of C's standard library, ..., without any
overhead. Then, a D primitive called emplace allows you to construct objects
at specified memory locations (a la C++'s placement new operator)".

The emplace function is in the std.conv library and is the basis for
constructing objects outside of the control of the garbage collector.

My understanding is that most library functions do not care about whether you
are using garbage collection or not. Library functions are usually written in
a parameterized way such that you can use any appropriate object; so long as
it has the right methods.

Take a look for example at the std.algorithm library:
<http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html> I don't think
anything there cares whether you use garbage collection for your types or not.

------
malkia
Great article. I guess there would be an article about linking C++ code - now
that's something that's hard to parallelize.

The IncrediBuild guys have some success there, but you have to link from the
.obj files, not .lib (okay if your project is setup like that, but also it
does not work always).

We have found that heavy templates usage creates lots of symbols that point to
memory get coalesced later, and this also slows down the linker.

~~~
atlei
For more about Incredibuild:

\- <http://gamesfromwithin.com/how-incredible-is-incredibuild>

My summary of the article (I haven't tried it myself): \- can improve a full
build compile time \- will probably slow down incremental build compile time

~~~
malkia
I have interoperability mode turned on, so I can both compile with
IncrediBuild and normally.

But IB does not treat everytime in the .vcproj file as MS does. For example we
used to link statically to certain libs, and later added them with the sourc
code, and put dependancies in the .sln file. Well we forgot to remove the
references, and guess what - MS ends up with one version, IB the other.

In our case IB was ignoring the .lib files, but taking directly the .obj files
and linking with them (this has other side effects, for the globally
initialized C++ objects).

But still it's time saver. We often have bad .pdb, .obj files produced, locked
situations, etc.

We even use it for Makefile builds, but again such issues are popping out.

It's a clever system, that wraps the whole I/O and runs any process on a
different machine, but all I/O is still done on the machine it's coming
from... I wish that was somehow built in modern OS's.

------
JoeAltmaier
Hm, small point, but the linker may not actually fold identical templates.
Visual C does; gcc sometimes does not.

