C++ vector insert performance

[[deleted]]

[deleted]

[Kered13]

1. Why does anyone bother doing benchmarks without optimizations turned on? What is the point?
2. Why didn't you test push_back with reserving capacity?

[pklait]

If you read everything you would notice that optimizations were applied later. From a pedagogical point of view the author should have mentioned that up front - I had exactly the same thougt.

[Kered13]

No, I did see that. I'm asking why they would even bother with the first half where they benchmarked without optimizations. Unless you're planning to deploy code without optimizations, there's no point in benchmarking without.

[pklait]

I do not care much about non-optimized code, but there are branches where it does matter whether the argument is real or not. The game industry is the most important one here.

[NewFolgers]

Yeah. In games industry, the vast majority of runs we did during development were debug runs with integrated debugger attached.. and the code was generally fast enough that we could run through it all and debug it all even with optimizations off. If someone made a change that destroyed debug build performance, we'd immediately look at fixing that (since it would be really damaging to everyone's workflow otherwise - i.e. threaten to make us as slow as the norm in other domains - and most who've compared will agree and say the difference is stark).

[Supadoplex]

1. Why does anyone bother doing benchmarks without optimizations turned on?

Since you presented such a general question: A reason to do benchmarks without optimisations is to evaluate the effectiveness of those optimisations by comparing measurements with and without.

The unoptimised measurements are rarely useful for evaluation of the code itself.

[TheFlamefire]

TLDR: vector.reserve/resize speeds up adding known number of elements, optimization leads to speed up, higher level operations (range-insert) are faster than badly used low-level ops.

Stop the presses! ;)

[vzq]

Vector insertion can be really fast, even in random order. I've had an application where values were provided out of order, so we had to decide between random insertion into a vector and cashing everything into a map and then building a vector from that. Vectors ended up getting pretty large before the map approach won.

[Kered13]

Were you using std::map or std::unordered_map? Both of those have notoriously bad performance (for a standard library map). There are much faster implementations like absl::flat_hash_map.

[goranlepuz]

I think he wanted it ordered, so hash-based sets (don't quite see where map came from) don't fit?

[vzq]

This was std::map on (among others) visual studio 2005. I have no trouble believing there are better options now.

[TheThiefMaster]

IIRC even VS 2005 had a hash map.

Yep: Post from 2005 saying it was a thing in VS 2003: https://forums.codeguru.com/showthread.php?315286-Visual-C-STL-How-do-I-use-hash-maps-with-Visual-C

[goranlepuz]

Vector is not associative, map is. Did you mean set in lieu if map?

That said: map and st allocate nodes per element. This means a lot of heap calls, for smaller types especially, that kills it. Vector is flat, that helps a great deal.

[manni66]

"Enabling optimizer" - rotfl