From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-01-18 01:19:44
Phil Richards wrote:
> Well, I've finished the cut over to boost::mpl::vector.
> I now have something that is functionally equivalent (well, pretty much),
> has the possibility for extensionality being done fairly cleanly now - SI
> is defined as:
> struct si
> typedef boost::mpl::vector7<u::kilogram, u::meter, u::second,
> u::ampere, u::kelvin, u::candela,
> u::mole> units_type;
> (It is trivial, therefore, to define new unit systems. I'm in the middle
> of a secondary cut-over for how things like "second" are defined.)
> BUT, and this is a big but, the compilation times are appalling. They
> have surpassed Matthias' :-) From the 3 seconds that I had with a fixed
> vector, I hit about 6 seconds just by doing the main calculations with MPL
> stuff. When I cut-over the unit conversion code to a rather tidy
> compile-time fold-based approach, it the time increased to a little over
> 10 seconds.
> The killer has been cutting over the output routines to a fold-based
> approach - just doing this has increased compilation times to 150 seconds.
Sounds like something is wrong. Let's figure it out.
> Are there any obvious things I should be looking at?
O(n*n) algorithms :).
> Especially with
> respect to things like using mpl::fold, mpl::zip_view, mpl::vector - I
> don't use much more than those.
> (Compiler is gcc 3.3.2.)
The code you've posted seems pretty innocent. I'd need a compliable test
case which reproduces the problem to be able to say more.
> There are things I can do to step-back from the pure-MPL approach I'm
> taking, but the solution I've got reminds me of my functional programming
> days and gives me a warm fuzzy feeling.
-- Aleksey Gurtovoy MetaCommunications Engineering
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk