Subject: Re: [boost] [proto] Looong compile times and other issues
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2011-09-12 01:16:03
Le 12/09/2011 05:42, Eric Niebler a écrit :
> 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.
and the fact that the _impl struct are all made like :
instead of a more CT friendly
template<class Tag, class Dummy=void>
I think heller started played with that and got some measurable CT
THe C++11 rewrite is obviously a long term project, MPL has to go this
way too (My secret dream is to merge Fusion and MPL and have MPL be
deltype over Fusion calls) and I think at some point we should start
thinking of doign it. Fusion laready have a 0x implementation in the SOC
sandbox folder but I think it can be pushed a bit more but it'll require
us to have access to a couple of strong C++11 enabled compilers.
The CT performances of our infrastructure trifecta (Fusion/MPL/Proto)
should become target #1 at some point.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk