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. 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 Proto. -- Eric Niebler BoostPro Computing http://www.boostpro.com