thanks for the deque tip. i however need to remove from any index (eg
remove the 3d element). i just used the remove head example in the
code to get the worst case senario.
yes, it is interesting that vector performs well when datatypes are
small and there are few items (even when size() is 256).
i will be using boost::shared_ptr<T>. so i'll have to do some tests
with this datatype.
so vector may be the best bet for the following requirements:
- only insert to end
- remove from any index
- average size of 64 items
- frequent iteration
- datatype: boost::shared_ptr<T>
i dont like the fact that vector resizes often when small. to get
around this i may set the capacity to 64. memory shouldn't be an issue
these days...agreed?
i ran some tests on the impact of the default capacity. i however
didnt find much difference in performance.
On 7/13/06, Brian Budge
Another factor, which affects the constant Mikhail is talking about, is if the vector can fit into cache. This will make a huge difference. If you could allocate your nodes to be close together in memory (ie. use Cory's suggestion of boost::pool), you should be able to reap more cache coherency benefit in your list too.
On 7/12/06, Mikhail Kubzin
wrote: There is a simple rule for choosing a container. If the number of elements in it is not huge then use vector.
The reason is that although the complexity of for instance deleting an element from a vector is greater than one from a list, but O-differences (here linear-time vs. logarithmic-time) only matter if the containers are big enough to swamp the constant factor, which for containers of small objects like doubles frequently doesn't happen until after container sizes exceed several thousand elements.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users