This reminds me of Dürrenmatt's "Die Physiker "(https://en.wikipedia.org/wiki/The_Physicists).

While this has indeed very scary implications, one should be aware that if it's thinkable, eventually it will be thought (I'm paraphrasing here).

Maybe in a logarithmic plot this would look differently, but it seems to me that std::vector performs quite well in particular for few elements. So why would I bother with smallVector if simple std::vector is on par in their (supposed) prime discipline?

Vector can be slow if you create and destroy them a lot, since they allocate. You can work around to some extent by providing a custom allocator, but using something like SmallVector or absl::InlinedVector can be much faster when the N is known.

Or if it's fully static size, just use std::array. You'd be surprised how often people use known static size or static max size vectors instead.

Yeah, that's one of my biggest pet peeves when looking at other people's code (along with unnecessary dynamic allocations in general). One of the reasons I perhaps irrationally still prefer C++ to Rust is the pervasive use of dynamic arrays of known static size in the latter's documentation, and how it makes fixed-size arrays much less ergonomic to use than dynamic arrays.

Sure. Horses for courses. Array is great when you have exactly N. InlinedVector is handy when you have <N 99% of the time.

I tried this at some points where I often have to allocate dynamic memory though I knew an upper bound (no static size, though). Got some nice (and easy) extra performance, thank you (and the others who replied to my comment) very much for the hint!

I'm in games, and we really do have lots of vectors of maybe 8 or so elements. The small wins add up across the entire codebase.

Because you are developing LLVM or a similar performance critical project with lots of small vectors.

13 minutes -> 11 minutes: "Elapsed time goes down by 15%."

3:16 minutes -> 1:42 minutes: "We get a roughly 90% speedup in elapsed time."

What's the formula for the "speedup"? I think it would be more expressive if one would compare it in the same terms.

Or just print the numbers, and let the reader get whatever they want out of that...

On this subject: https://randomascii.wordpress.com/2018/02/04/what-we-talk-ab...

I think the math was done inversely.

1:42 -> 3:16: 90% slowdown?

We could use a logarithmic scale instead of percentages. If we defined a decibel scale for time then this would be a 2.83 dB change both ways (if we defined dB-sec as 10*log10(time/(1 sec)) ).

Is someone aware of a similiar post replacing "Physics" with "Computer Science"?