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-08 14:56:51

I've done some testing based on the suggestions:

Adding a destructor to the 'dummy' types doesn't seem to make a 
difference. Adding boost::blank as the first type however makes a hugh 
difference:

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

Variant type: v2    Foo logic:C		Original
Obj size: 80.6MB
Exe size: 356KB
Pdb size: 13.6MB
Build time: 8:46
Peak commit: 1.4GB

Variant type: v2    Foo logic:C		Add boost::blank as first type
Obj size: 2.6MB
Exe size: 348KB
Pdb size: 11.6MB
Build time: 1:03
Peak commit: 600MB

Drawback of this approach seems to be that each visitor needs to have an 
operator()() receiving a boost::blank&; not a big problem anyway.

I failed to apply the patch-file on the 1.38 revision; either there is a 
problem with the patch.exe that i downloaded (for win32) or the 
patch-file doesn't match this revision. When you can send me a modified 
variant.hpp based on the file attached, then i will be happy to run some 
tests.

I was wondering whether the found behavior is a bug or not; after all it 
seems to be functionally correct but it just doesn't scale very well. 
When this problem can be fixed in the variant.hpp then i guess that's 
preferred but what are the consequences at functional level and/or 
runtime performance?

Paul