Re: [boost] Interest in a container which can hold multiple data types?

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]
> for
> > >> such a container, and I believe in the later case such that the types
> are
> > >> 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
> > >
> http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.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:
>
> https://www.dropbox.com/s/qy9qbf0eyf1itsy/het_collection.cpp?dl=0
>
> Timing for for_each on 1k-10M elements (MSVC 12.0):
>
> het_collection;vector_variant;sorted_vector_variant;
> for_each:
> 1000;0.0225453;0.0822232;0.0840048;
> 10000;0.0229827;0.0828214;0.0821378;
> 100000;0.0229448;0.081315;0.0839802;
> 10000000;0.0250193;0.0906496;0.0879296;
>
> 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.