2015-05-06 22:41 GMT+08:00 Boris Rasin
On 5/6/2015 3:58 PM, Joaquin M Lopez Munoz wrote:
Boris Rasin
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
> and sorted vector > vs. a collection class het_collection 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.