Re: [boost] [proto] Looong compile times and other issues

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:
>
>    at_c<N>(v);
>
> where v is a fusion vector instantiates:
>
>    lazy_disable_if
>    is_const
>    result_of::at_c
>    result_of::at
>    mpl::int_
>    detail::tag_of
>    extension::at_impl
>    extension::at_impl::apply
>    mpl::at
>    detail::ref_result
>    add_reference
>
> 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.
>

^ This

and the fact that the _impl struct are all made like :

template<class Tag>
struct at_impl;

template<>
struct at_impl<some_tag>

instead of a more CT friendly

template<class Tag, class Dummy=void>
struct at_impl;

template<class Dummy>
struct at_impl<some_tag,Dummy>

I think heller started played with that and got some measurable CT 
performance increase

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.