Boost logo

Boost :

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-09-18 11:08:59

>From: "John Torjo" <john.lists_at_[hidden]>

> > Ok, I haven't timed "typical use"; the only tests I've done in this
> > is running the unit tests, but much of the time involved in that may
well be
> > taken by the test framework, as it uses mpl::for_each to iterate in two
> > dimensions, taking a list of traits, and a list of types to test for
> > trait, which generates thousands of tests.
> >
> > The unit tests take a rather long time to compile on Intel C++
> > several minutes), but shorter on on MSVC, or g++.
> that's a bit of a turn-off for me.
> I'm getting more and more annoyied by the fact that every time something
> *really cool* is discovered, it hits the compiler-time barrier.
> As I've said in posts to c.l.c++.m, maybe it's time for a new language...

Or compilers optimised for heavy template use. :)

There might be ways of optimising compilation time, but it may be very

I've done some benchmarks, using the unit tests. The results are given

System specification
Pentium II 350 MHz
384 MB 100 MHz RAM


Intel C++ 7.1 - No debug info, optimisations off
21 traits, 925 tests - 5 min
46 traits, 1981 tests - 21 min

MSVC 7.1 - No debug info, optimisations off
21 traits, 925 tests - 2 min
46 traits, 1981 tests - N/A - fatal error C1204: compiler limit : internal
structure overflow

g++ 3.2 - No debug info, optimisations off
21 traits, 925 tests - 7 min
46 traits, 1981 tests - > 30 min (*)

(*) This used a lot of memory, > 330 MB, apparently leading to virtual
memory trashing, and dramatic drop in processor utilisation, so in the end I
stopped the compilation.

Note that, as mentioned above, much of the overhead may be due to the test
setup - it builds a long instantiation stack with mpl::for_each in two
dimensions, and as you can see, on Intel C++ (EDG), the time taken doesn't
grow linearly with the number of tests, but rather quadratic, or something
like it.

The traits are rather simple in structure - there's no recursion in the
library itself, although it might be in the mpl::and_<>, mpl::or_<> and
mpl::not_<> components that are used, and/or use of the PP-lib.

Before doing any optimisation, I think one should first determine if there
_is_ a problem, by benchmarking a real-life program with and without concept



Boost list run by bdawes at, gregod at, cpdaniel at, john at