Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk