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 14:08:38

Op 9-1-2011 15:03, Mathias Gaunard schreef:
> On 08/01/2011 23:34, Dave Abrahams wrote:
>> At Sat, 8 Jan 2011 23:34:47 +0200,
>> Igor R wrote:
>>>
>>>>> If it's really just shared_ptr's in the variant, I would seriously
>>>>> consider replacing it with shared_ptr<void> (with a type tag if
>>>>> necessary). Just a thought.
>>>>
>>>> Seriously, could be a big simplification and speedup vs. using using
>>>> variant.
>>>
>>> Could you please elaborate a bit on this? How to replace
>>> variant<shared_ptr<T> > with shared_ptr<void> and a tag? Wouldn't the
>>> tags be wrapped in a variant anyway?
>>
>> No, tags could be an enum or a type_info*, for example
>
> An enum (or an integer) is a much better idea than a type_info*, since
> it can be used in a switch statement, and can be mapped naturally to a
> type in a list of types as an index.
>
> Writing a variant replacement is actually quite easy, and doing so would
> greatly reduce your compile times.
> Variant is old, full of quirks, and doesn't scale well. Why it even
> requires its MPL input sequence to be Front Extensible (which it doesn't
> even state in its documentation) is beyond me. This is a very annoying
> limitation that makes it impractical to use with a large amount of
> types, since compatibility with joint_view would be very nice in that
> situation.
>

We use following logic to work with subsets:

   //Join the two mpl sequences
   typedef boost::mpl::joint_view<Mplv1_t, Mplv2_t>::type Mplv_t;
   typedef boost::make_variant_over<
     boost::mpl::copy< //make_variant_over requires an 'extensible 
sequence' while joint_view creates a forward sequence
       Mplv_t,
       boost::mpl::back_inserter<boost::mpl::vector0<> >
     >::type
   >::type v_t;

This solution probably takes quite some compile-time as well but since 
the sequences only hold 5 or 6 types its sufficient. It does allow to 
use enable_if(contains<mplv1_t, T>) in the static-visitor functor which 
gives some really nice code; meaning efficient and easy to understand.

Paul

> The best option is probably to declare your variant-like type using a PP
> list of types. This way you can directly generate the matching switch
> statement with minimal overhead.
> If you need to take a MPL list as input, the best advice is probably to
> use Steven Watanabe's switch library, as it can generate a switch
> statement that converts runtime integers into compile-time ones.