At Sat, 26 Feb 2011 17:37:03 +0100, Domagoj Saric wrote:
"Dave Abrahams" <dave@boostpro.com> wrote in message news:m2sjvc2l36.wl%dave@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