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

2015-05-06 21:55 GMT+08:00 Joaquin M Lopez Munoz :

TONGARI J writes:

...

2015-05-06 20:58 GMT+08:00 Joaquin M Lopez Munoz :

...

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:

[...]

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.

Yes, definitely I'm not fully getting your point, my apologies. What do you mean by ordered het_collection? As it is designed het_collection clusters values of the same type together.. Do you mean a version where the order of insertion is arbitrary as in a vector? If so, any sensible design of such a het_collection_v2 would boil down to esentially the same as vector<variant>, I'd say.

What I have in mind is a het_collection with interval/span based structure for ordering. You can think it as a het_collection that also retains the insertion order. And I agree that in general case, vector<variant> is the choice, only when you know the values of the same type tend to lie together beforehand could a ordered het_collection give better performance.