|
Boost : |
Subject: Re: [boost] Interest in a container which can hold multiple data types?
From: Boris Rasin (boris_at_[hidden])
Date: 2015-05-06 10:41:08
On 5/6/2015 3:58 PM, Joaquin M Lopez Munoz wrote:
> Boris Rasin <boris <at> pointx.org> writes:
>
>> 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.
So traversing such "unordered" het_collection is indeed faster. Thanks
for the data. The question is how useful such container would be in real
life if it only supported "unordered" traversal, i.e. did not satisfy
requirements of "sequence container"? As I suggested previously, one
could add additional internal index container to keep track of linear
element arrangement, allowing both linear traversal and fast "unordered"
traversal when desired. Does this make any sense?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk