Larry Evans wrote:
On 03/10/08 11:29, Eric Niebler wrote:
AMDG
Markus Werle wrote: [snip] The typelist used there is not Fusion-compatible, but expr<> as a whole is. For a while, I was using mpl::vector<> as the second template
Steven Watanabe wrote: parameter to expr<>, but I changed to a very simple custom type because it improved compile times.
Could you give some estimate as to how much it improved compile times? Do you have handy a benchmark test to show this? I would like to try this benchmark with the variadic template compiler to see how close they are.
I switched away from mpl containers very early on. I don't have any of the old code for you to test. I recall compile times improved by about ~8-10%. The issue is accessing the members. Going thru mpl::at_c<> to get at each child forces an extra template instantiation. Ditto for getting the length via mpl::size<>. These template instantiations add up and cause a measurable perf hit.
I know you've already tried the variadic compiler, but I'd like to try the benchmark myself and maybe show the results and code to Douglas Gregor so that maybe he can figure out why the variadic compiler is not improving compile times. As you noted in a private email to me, the basic reason is:
Instantiating templates is expensive. By comparison, expanding a macro is cheap.
However, maybe the benchmark would prompt Douglas to look for ways to improve the compiler's template instantiation speed.
I've already spoken with Doug about it. Variadics are great and do improve compile times for variadic functions, esp. when combined with rvalue refs. Variadic class templates are another matter. The only way to metaprogram with them is with recursive template instantiations. That means instantiating lots of templates. The preprocessor can improve the situation by doing loop unrolling, but in the limit, the number of template instantiations is going to be linear with the length of the parameter pack. If you want to play with the variadic Proto code, you can find it at branches/proto/v3. I recently resurrected this branch because some people on the std committee were interested in it. It's not production code, though. -- Eric Niebler Boost Consulting www.boost-consulting.com