5 ms·
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
by LHxB 8y ago
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?
- orbifold 8y agoBecause you are developing LLVM or a similar performance critical project with lots of small vectors.
- s3cur3 8y agoI'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.
- shereadsthenews 8y agoVector 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.
- AstralStorm 8y agoOr 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.
- shereadsthenews 8y agoSure. Horses for courses. Array is great when you have exactly N. InlinedVector is handy when you have <N 99% of the time.
- smitherfield 8y agoYeah, 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.
- LHxB 8y agoI 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!