Subject: Re: [boost] [fusion] improving compile times
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-06-02 10:06:09
Eric Niebler wrote:
> Larry Evans wrote:
>> On 06/01/09 20:26, Eric Niebler wrote:
>>> I'm attaching a simple patch to vector_n_chooser.hpp that replaces
>>> some template metaprogramming with preprocessor metaprogramming in
>>> the interest of improving compile times. I found this hotspot
>>> through profiling,
>> Could you post your benchmark code that showed the improvement in
>> compile speed? I'd like to eventually try it with a variadic template
>> compiler version of fusion vector.
> I confess that I'm not actually benchmarking compile speed; rather,
> I'm benchmarking the number of template instantiations as reported by
> Steven's template profiler. I'm profiling TMP-heavy code like some of
> Proto's and xpressive's tests and cherry-picking the worst offenders.
> The Fusion vector_n_chooser patch knocked off 100's of template
> instantiations, for instance.
>> Somewhat off topic:
>> What I'd really like to see is someone explain how metaprogramming
>> improves compile speed. Steven said earlier that the slowdown
>> depends on the template:
>> I would have guessed that the more template instances that,
>> are created, then the slower the compile time. However,
>> Steven's remark made me wonder. What I'm guessing
>> is that if the template metaprogram produces a lot of
>> intermediate results, then it might be better to
>> use preprocessor metaprogramming to just produce the
>> final result. Is that about right or is it more
> My experience matches yours: more instantiations --> longer compiles.
> I wonder what Steven's experience is. Steven?
For macro optimizations that substantially reduce the number
of template instantiations, that's a pretty safe assumption. I
definitely don't trust it for micro optimizations, though.
Also, be wary of the total instantiation count produced by my
tool. It's easy to change it by changing the #includes for instance.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk