|
Boost : |
Subject: Re: [boost] Interest in a container which can hold multiple data types?
From: TONGARI J (tongari95_at_[hidden])
Date: 2015-05-07 04:52:16
2015-05-06 22:41 GMT+08:00 Boris Rasin <boris_at_[hidden]>:
> 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?
>
FWIW, I made a simple proof-of-concept, it's basically a het_collection
with ordering.
https://gist.github.com/jamboree/5a5797e8869168cc64d9
Maybe someone would give it a performance test.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk