Hacker News Reader

Comment by LHxB | Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com