Re: [Boost-users] large variant performance compared (50 elements)

Subject: Re: [Boost-users] large variant performance compared (50 elements)
From: Larry Evans (cppljevans_at_[hidden])
Date: 2011-01-15 19:14:30

On 01/15/11 17:43, Larry Evans wrote:
> On 01/15/11 08:54, Paul wrote:
>> It looks like we are heading for an alternative approach (again). Based
>> on the boost::variant i'm writing my own variant that is optimized to
>> only hold shared_ptr's.
>>
>> First test seem promising i can finally create variants with 200 types
>> in 2 sec compilation :) However binary invokation is even here quickly a
>> problem, its generating 'paths' quadratically, 50 bounded types produce
>> 2500 paths....
>>
> [snip]
> I think maybe that should be expected.  After all, the number of
> binary signatures, where the first is from set, S1, and the second
> is from set, S2, and the sizes of S1 and S2 anr N1 and N2, then
> there has to be N1*N2 different signatures; hence, if N1=50
> and N2=50, then there's 2500 different signatures.
> 
Actually, I now remember encountering this problem and
reporting it here:

  http://article.gmane.org/gmane.comp.parsers.spirit.general/20163

BTW, on a related note (although not much use to you since you
don't have a variadic template compiler available), there's
a comparison of the variant container and one_of_maybe container
in boost vault:

http://www.boostpro.com/vault/index.php?action=downloadfile&filename=variant_test.zip&directory=Data%20Structures&

It has a nice graph of compile times vs number components.
It shows one_of_maybe is faster and grows more slowly as
the number of components increases.

HTH.

-Larry