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

Subject: Re: [Boost-users] large variant performance compared (50 elements)
From: Paul (peebor_at_[hidden])
Date: 2011-01-09 13:55:56

Op 9-1-2011 1:32, Steven Watanabe schreef:
>
> Does the cost increase continuously, with the number of elements?
>

Some more testresults, i've measured compile + link times for 
10,20,30,40,... number of elements.

typedef boost::mpl::vector75<
  boost::shared_ptr<C1>,
  boost::shared_ptr<C2>,
  boost::shared_ptr<C3>,
  ...

No boost::blank added to the sequence, variant.hpp not patched (so 
original version). Also i removed the copy/assignment so its only 
construction of the variant, and 1 static-visit.

size: 10 = 0:09
size: 20 = 0:12
size: 30 = 0:19
size: 40 = 0:34
size: 50 = 1:02
size: 60 = 1:51
size: 70 = 3:09
size: 80 = 5:07 cl.exe working set = 1.7GB
size: 90 = 9:58 compiler out of heap space (commit 3.2GB)

>
> Maybe in a few days. boost::mpl::vector75 doesn't exist
> without some extra work.
>

Sizes beyond 50 (if i remember correct) are not supported by default 
with the boost distribution, but there is a script somewhere to generate 
the headers (such as boost/mpl/vector/vector100.hpp, 150, 200, ...).

It looks to me that the variant may not be that feasible for >50 types. 
Ofcourse it may be larger or smaller depending on the hardware and your 
patience ;) and ofcourse also to what extend the variant is used. We use 
for instance a simple struct to wrap the variant (fwd decl the struct) 
so the load is not exposed that much.

Paul