Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at