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 18:43:55

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.

IOW, the binary visitor would have to have member functions
something like:

  template
  < typename... S1
  , typename... S2
  >
struct bin_viz
{
  void operator()(S1_0& s1, S2_0& s2);
  void operator()(S1_0& s1, S2_1& s2);
  void operator()(S1_0& s1, S2_2& s2);
  ...
  void operator()(S1_0& s1, S2_n& s2);

  void operator()(S1_1& s1, S2_0& s2);
  void operator()(S1_1& s1, S2_1& s2);
  void operator()(S1_1& s1, S2_2& s2);
  ...
  void operator()(S1_1& s1, S2_n& s2);

  void operator()(S1_2& s1, S2_0& s2);
  void operator()(S1_2& s1, S2_1& s2);
  void operator()(S1_2& s1, S2_2& s2);
  ...
  void operator()(S1_2& s1, S2_n& s2);

  .
  .
  .
  void operator()(S1_m& s1, S2_0& s2);
  void operator()(S1_m& s1, S2_1& s2);
  void operator()(S1_m& s1, S2_2& s2);
  ...
  void operator()(S1_m& s1, S2_n& s2);

};

  where S1 is a typelist with members S1_0, S1_1, ..., S1_m
        S2 is a typelist with members S2_0, S2_1, ..., S2_m

IOW, there would be m*n member functions; hence, the
quadratic compile times.

However, I'm just guessing now, I've not actually
measured it or tried to actually show this is the
reason, but it would be the first place I'd look.

HTH.

-regards,
Larry

};