Subject: Re: [boost] Interest in a container which can hold multiple data types?
From: TONGARI J (tongari95_at_[hidden])
Date: 2015-05-06 10:32:07
2015-05-06 21:55 GMT+08:00 Joaquin M Lopez Munoz <joaquin_at_[hidden]>:
> TONGARI J <tongari95 <at> gmail.com> writes:
> > 2015-05-06 20:58 GMT+08:00 Joaquin M Lopez Munoz <joaquin <at> tid.es>:
> > > Ok, understood. I've written a small performance test of
> > > vector<variant<Ts...>> and sorted vector<variant<Ts...>> vs. a
> > > collection class het_collection<Ts...> storing values of the same
> > > type contiguously and providing a specialized for_each memfun:
> > >
> > > [...]
> > >
> > > So, unsurprisingly, het_collection does much better as for_each
> > > on a vector<variant> needs to check type on each iteration. Sorting
> > > the vector so that values of the same type lie together does not
> > > have any impact on performance.
> > >
> > In case that you misunderstood my previous post, the assumption that when
> > values of the same type lie together could result in better performance
> > was for ordered tuple_vector-based sequence, not for vector_variant.
> > Your benchmark result is indeed what we expected, what I'd like to see is
> > the comparison between *ordered* het_collection and vector_variant.
> Yes, definitely I'm not fully getting your point, my apologies. What
> do you mean by ordered het_collection? As it is designed het_collection
> clusters values of the same type together.. Do you mean a version where
> the order of insertion is arbitrary as in a vector? If so, any sensible
> design of such a het_collection_v2 would boil down to esentially the
> same as vector<variant>, I'd say.
What I have in mind is a het_collection with interval/span based structure
You can think it as a het_collection that also retains the insertion order.
And I agree that in general case, vector<variant> is the choice, only when
you know the values of the same type tend to lie together beforehand could
a ordered het_collection give better performance.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk