4 ms·

> std::vector is super fast for basically everything except for dynamic resizing. Resizing it is just fine, there's not really anything unexpectedly slow there

> std::vector is super fast for basically everything except for dynamic resizing. Resizing it is just fine, there's not really anything unexpectedly slow there. Rather, the big downside to std::vector is the lack of small size optimization (something std::string has, so too does std::function for that matter). That's the big win for things like absl's inlined_vector https://github.com/abseil/abseil-cpp/blob/master/absl/container/inlined_vector.h https://github.com/abseil/abseil-cpp/blob/master/absl/contai... It's an ABI break to add small-size optimizations to std::vector at this point so unfortunately while there's not really anything in the API requirements that would prevent it, compatibility concerns pose a formidable barrier

account42 5y ago
> It's an ABI break to add small-size optimizations to std::vector at this point so unfortunately while there's not really anything in the API requirements that would prevent it, compatibility concerns pose a formidable barrier It's also a tradeoff as you would either need additional branching on access (this is what most std::string implementations do) and/or bloat the size of all vector objects, even those that will never fit into the static size.
- kllrnohj 5y ago
  It's a tradeoff the user can make, not something the STL needs to generically know like std::string does. If you look at inlined_vector (or similar implementations), the static size is specified in a type parameter, not something automatic. So just have it be 0 if you want it to behave like std::vector does currently. As such, no downsides to adding this to the type other than the ABI breakage. Default the size to 0 and you preserve API compatibility, even.