Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2004-01-09 18:07:34

> I'm curious about how bad the compilation time really is
> and what the cause is.

The test programs take around 30 seconds to compile on my machine. As
as I have been able to tell the compilation is slow for a few reasons :

1) my algorithms are not optimal because I'm using mpl::list where I'd
really like
an mpl::map. this should be resolvable in the not too distant future
as the good
wizards of MPL already have pre-release implementations which I hope
will be

2) the compile-time manipulation of the typelists is pretty extensive :
they are
basically unconstrained, so tag/exponent pairs can appear in any order,
be repeated. This means there is significant overhead; for example to
add two
dimension lists, I need to implement a set-like compare operator which
is, for
the aforementioned reason, not very efficient. For multiplication and
two dimension lists must be merged, sorted by tag type, and reduced.

> One question I had was does the code compile faster if you
> use only the dimensional analysis library with, say, 2 or 3
> basic units and the associated derived units, instead of
> all 7 physical dimensions?

Since I use typelists, dimensioned analysis compile time will depend
(at the moment
as O(N^2)) on the number of elements in the type lists. The
dimensional analysis code
has nothing to do with 7 (or any other number) of physical dimensions -
it is purely a
system for algebraic manipulation for completely arbitrary typelists.
For example,

mpl::list<dim<t1>,dim<t2,-2>,dim<t3/3>,dim<t4> >

represents (t1 t3^(2/3) t4^3)/(t2^2)

where t1 etc... are just structs defined as : struct t1 { };

> -----------------------------------------------------------------------
> ----------------------------
Matthias Schabel, Ph.D.
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT 84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
mschabel at ucair med utah edu

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