Subject: Re: [boost] Interest in a container which can hold multiple data types?
From: TONGARI J (tongari95_at_[hidden])
Date: 2015-05-06 09:38:39
2015-05-06 20:58 GMT+08:00 Joaquin M Lopez Munoz <joaquin_at_[hidden]>:
> Boris Rasin <boris <at> pointx.org> writes:
> > On 5/5/2015 7:49 PM, Joaquin M Lopez Munoz wrote:
> > > TONGARI J <tongari95 <at> gmail.com> writes:
> > >
> > >> If the data sequence shows some affinity, I guess an ordered
> > >> tuple_vector-based sequence can provide some performance benefit in
> > >> traversal (with some crafted for_each method).
> > >>
> > >> That is, a sequence of [AAABBB] may be traversed faster than [ABABAB]
> > >> such a container, and I believe in the later case such that the types
> > >> uniformly distributed, vector<variant> will perform better.
> > > I wrote something on this some time ago, maybe worth having a look at:
> > >
> > > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html
> > >
> > >
> > Interesting read, thanks for the links. Although in this case we are
> > talking about vector<variant> which stores data by value.
> 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:
> Timing for for_each on 1k-10M elements (MSVC 12.0):
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk