Boost logo

Boost :

Subject: Re: [boost] [parameter] Compile-time performance
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-02-25 10:24:45

At Fri, 25 Feb 2011 13:58:48 +0100,
Domagoj Saric wrote:
> I have an in-house framework a part of which is very similar to
> Boost.Parameter so I tried to refactor it to use Boost.Parameter and,
> unfortunately, noticed a big compile-time hit (the project has a very large
> number instantiations of class templates with 'named non-type template
> parameters').
> With my code (and MSVC++ 10) build time was ~56 seconds with a maximum
> cl.exe memory allocation size of ~720 MB. After switching to Boost.Parameter
> build time whent to ~2:24 seconds with a maximum cl.exe memory allocation
> size of ~815 MB.
> The most likely suspect is the usage of a forward-sequence for parameter
> type storage (argument packs) from which you fetch passed parameters using
> key-based lookup with the value_type<> metafunction. In my code I use an
> associative container (mpl::map) for the task which has a
> 'natural'/'efficient' key-based lookup...

Heh, I came up with the idea for the O(1) instantiation mpl::map
mechanism and used the same basic mechanism for lookup in
Boost.Parameter, so what you're saying is a bit surprising.

> To confirm this I minimally changed the Boost.Parameter-based version of my
> code only to use mpl::maps instead of Boost.Parameter ArgumentPacks and
> built time fell to ~58 seconds...(true, this does not have all the
> compile-time check for correct usage and concept validation that
> ParameterSpecs and ArgumentPacks have but I'd expect this to have a much
> smaller effect than key-based lookup on a forward sequence)...

I think you should do some more measurement :-)

> Is there an inherent issue that forbids the use of an associative container
> for ArgumentPacks or can this be fixed?

ArgumentPacks are associative. In fact, though, Matt Calabrese proved
that the basic strategy of MPL associative containers did not produce
the expected speedups. See "Instantiations Must Go" at for more

I would, however, love to speed up Boost.Parameter so if you find the
actual cause or a way to do it, I'm all ears!

Dave Abrahams
BoostPro Computing

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