Subject: Re: [boost] [proto] Looong compile times and other issues
From: Eric Niebler (eric_at_[hidden])
Date: 2011-09-11 23:42:54
On 9/11/2011 9:20 PM, Joel de Guzman wrote:
> On 9/12/2011 1:44 AM, Joel Falcou wrote:
>> - fusion is also a big hitter : lots of PP and lots of forced instanciation instead of
>> lazy specialization.
> PP: right, this can be fixed.
> lots of forced instanciation: I don't know what you mean.
> Can you please be more specific?
I can't speak for Joel F. here, but consider the templates instantiated
simply to access the Nth element of a fusion vector. From a cursory
inspection of sequence/intrinsic/at.hpp, the following call:
where v is a fusion vector instantiates:
I believe that it also must compute the return type of the const
overload of at_c in order to do overload resolution, so that many of the
above templates must be instantiated twice: once for a const vector and
once for non-const, and throw in an additional add_const. (And come to
think of it, Proto probably suffers from this problem too!)
That's a lot of templates for a simple element access. I didn't chase
the template breadcrumbs into mpl, so there may be more.
In Proto, I roll my own poor-man's heterogeneous sequences so I can save
template instantiations. I even use my own typelists over mpl::vector
because it had a measurable impact. And yes, I measured.
I'll say this: Fusion's implementation is BEAUTIFUL compared to Proto's,
which is an ugly, hard-to-maintain mess of PP gunk. Proto also exposes
fewer customization points. These were tradeoffs I made in the interest
of compile times, and it's still not enough.
A complete rewrite using decltype, rvalue refs and variadic templates
would GREATLY improve things. That's probably true for both Fusion and
-- Eric Niebler 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