From N3728:

Compilation speed is often gating in metaprogramming. In implementating t= he bases trait proposed in N3729 as a g++4.7 extension, I co= mpared the performance of returning a tuple type giving all the b= ase classes of a class with returning a simple typelist class con= taining no members and no recursive expansion. The simple typelist cla= ss was 60 times faster to compile. A built-in parameter list would pre= sumably be even faster than that. Given that the recursive member gene= ration in tuple provides no benefit for typelists, tupl= e-based typelists should probably be avoided for performance reasons&n= bsp;alone.

From N4115:

A class template that just = holds a parameter pack:

template <class... T&g= t; struct packer { };

This is = inspired by std::tuple, but it lacks members, so it could serve a= s an empty base class, and an object of the ultimate type could a= lways be instantiated (even if the parameter pack contains void&n= bsp;or some type that lacks a default constructor).

My experience with using std::tu= ple has been quite positive. My project does heavy meta-lifting with= what amounts to a first-order predicate unification engine, and it compile= s in seconds. While developing it, my tests with tuple versus an empty packer-like alternative showed no difference.

The key is that instantiating tuple is the only part that’s slow, but you never need to= instantiate a metadata type. Before a template-id is ODR-used, it only exi= sts as a disembodied name, not resolved to a partial specialization, and eq= ual in compiler cost to any other template-id of the same complexity, which= is just naked argument list (as proposed in N3728) plus a name. I&rsq= uo;m not sure what caused the slowdown mentioned in N3728. Perhaps GCC 4.7&= rsquo;s std::tuple_element instantiated somet= hing, but this no longer happens since 4.8.

= The tuple and tuple-like metafunction interface (std= ::tuple_size, std::tuple_element, etc)= are already specified so as to work without necessarily instantiating thei= r argument. Rather than adding new facilities to the standard, it would be = better to reflect common implementation practice in a requirement that they= not instantiate.

Few scenarios exist where pure t= ype-list instantiation is useful. If you add member metafunctions to the ty= pe-list class, then you pay for the declarations of members that are not us= ed. If you do not add members, then nothing is really instantiated. There i= s tag dispatching, but usage like tag< tuple= < x, y, z > > is more expressive.

= Codebases written on std::tuple and std::tuple_element exist, but nothing is written = against any other std::packer class or n= aked argument list facility, so there’s a compatibility argument. std::tuple is ready to produce runtime obje= cts when the user does want them, so there’s a convenience argument.<= /div>

—

For what it’s worth, my ap= plication does similar things to N4115, but a Boolean tuple-set-contains me= tafunction never came up. I ended up with only tuple= _upto, which slices a tuple from the beginning to just before a give= n type. (If the type is not found, the argument is returned unsliced.) In m= etaprogramming, if you’re going to use initial results to drive = further processing, it’s important to leverage memoization. I think B= oolean set arithmetic throws away too much information to make useful primi= tives under memoization. Or, perhaps the take-away lesson is that a generic= type-list processing library won’t be very useful if built piecemeal= from small proposals. Performance would be easier to preserve if is_contained_in generated memoized intermediate result= s for likely subsequent operations.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--Apple-Mail=_75100711-2170-4B68-85A1-DCA700621036-- .