Which is faster stl:list or stl:vector

Started by
20 comments, last by Bleakcabal 20 years, 1 month ago
quote:Original post by Anonymous Poster
You''re a *bit* too concerned about that particular number. I bet nobody''s going to just memoize it and use it as the holy guideline for all platforms. Given that I didn''t even specify how the benchmark weighted between different uses of the container and said that it''s "almost independent of the type of operations", note the vague "almost", how can you really read it so strictly?

If I hadn''t made any posts complaining about it, I''d have taken you up on the bet. And I''d give you 4 to 1 odds in your favor, too. If you didn''t want the number to be taken seriously, then you should have said yourself that it was compiler, stored type and platform dependent. But you didn''t, so I had to point it out. Plus, you''re post about T * vs. T implied that you, yourself believed that it was a meaningful number.
quote: I think you''re seriously underestimating the other readers here.

LOL. You haven''t been hanging around these boards long, have you? This kind of thing has happened here before. list vs. vector threads are fairly common, and someone, like you, will say vector is better for 50, 100 or whatever number of elements, and some newbie will parrot that number in the next thread without understanding anything behind it. Even with the amount of stink I''ve made about it here, I''m still not betting that someone hasn''t already walked away with the wrong idea already. You get the same kind of parrotting with people saying C++ is x% faster than VB, or ints are x% faster than shorts, or other similar meaningless numbers. And since you''re hiding behind the Anonymous Poster moniker, there''s no post history to go by to see whether or not you''re one of these parrotting posters; hence no basis to see whether or not you believe that 100 was some magic number yourself.
Advertisement
Performance isn''t a reason to choose list, you use list when the order matters, and either you need to perserve existing iterators during mutations (insertion & deletion) or you need atomic mutations (minimal bus-locking in SMP and minimal mutex hanging in multi-threaded environments). In exchange for this low-latency design objective, you sacrafice some throughput.

You can achieve decent insertion/deletion speed using a node cache (and splice them on), but every other operation on a list is slower than any other container. If the collection size is so large that vector is incapable, a list isn''t likely to solve the problem (a map, set, or hash is needed).
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

This topic is closed to new replies.

Advertisement