Re: [boost] Phoenix Reloaded

Subject: Re: [boost] Phoenix Reloaded
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-05-29 16:53:56

AMDG

Eric Niebler wrote:
> Also added to the wiki are the result of a template profile run over 
> miniphoenix.cpp. The results should interest Aleksey:
>
> Total instantiations: 2983
>
>               Location     count      cum.
> -----------------------------------------------------------
> C:\boost\org\trunk\boost/mpl/if.hpp(56)        59        59
> C:\boost\org\trunk\boost/mpl/if.hpp(44)        48       107
> <snip>
>
> The top two templates instantiated in this program are mpl::if_ and 
> mpl::if_c, respectively. The sad thing is that most of the 
> instantiations of mpl::if_c are totally unnecessary. mpl::if_ happens 
> to be implemented in terms of mpl::if_c so that any instantiation of 
> mpl::if_ causes an additional instantiation of mpl::if_c.
>
> If anything can be done to eliminate this unnecessary instantiation, 
> it'll speed up most template metaprograms across the board.

Something like this should work:

template<class Cond, class If, class Else, class Tester = boost::mpl::true_>
struct if_ {
    typedef Else type;
};

template<class Cond, class If, class Else>
struct if_<Cond, If, Else, boost::mpl::bool_<Cond::value> > {
    typedef If type;
};

but it may be less portable.

> For my part, I always take care in Proto to use mpl::if_c instead of 
> mpl::if_ for just this reason, but other libraries used by Proto don't 
> take this measure.

eval_if is even worse in libraries that use it heavily.

eval_if -> if_ -> if_c.

> Isn't profiling interesting?
>

In Christ,
Steven Watanabe