Re: [boost] [parameter] Compile-time performance

Subject: Re: [boost] [parameter] Compile-time performance
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-02-26 12:23:37

At Sat, 26 Feb 2011 17:37:03 +0100,
Domagoj Saric wrote:
> 
> 
> "Dave Abrahams" <dave_at_[hidden]> wrote in message 
> news:m2sjvc2l36.wl%dave_at_boostpro.com...
> > At Fri, 25 Feb 2011 13:58:48 +0100,
> > Domagoj Saric wrote:
> >> 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.
> 
> Well, the documentation 
> (http://www.boost.org/doc/libs/release/libs/parameter/doc/html/reference.html 
> @ 3.1 ArgumentPack) says "Every ArgumentPack is also a valid MPL Forward 
> Sequence..." and by looking at the ParametersSpec::bind<> implementation it 
> did look to me like a list/'chained'-like structure...

So does MPL's map.  It uses function overloading to do the lookup so
you don't have to walk the map.

> (although my knowledge of MPL and PP internals might quite be
> insufficient enough to mistake a list for a map...)...

It might :-)

> >> 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 :-)
> 
> Why? / You think that I am wrong in my assumption that key-based lookup on a 
> 'plain forward sequence' would trump type requirements validation?

I think you don't understand how MPL maps work and you missed the
mechanism in Boost.Parameter.  Therefore, I think you don't understand
the source of the slowdown.

> > 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!
> 
> If only it internally used MPL (and Fusion perhaps) instead of doing things 
> from scratch (e.g. template_keyword -> mpl::pair, argument pack -> mpl:map 
> ...) I might have an easier time following its internal flow (in the short 
> pauses from 'real work' :)...

We gave that approach serious consideration and would of course have
preferred to do it that way.  I don't recall the reasons we decided against it.

> Well, the first step I guess would be to disable type requirement validation 
> and measure the difference...
> 
> 
> ps. have you used SW's template profiler (with B.P.) ?

Not yet.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com