You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes, we should consider doing this. Some realistic benchmarks would be useful. For some more related discussion, see rust-lang/rust#4961.
The best example I can find of a resizable vector tuned for performance on modern allocators is FBVector. It starts at a minumum of 64 bytes, then grows by factors of 2 up to 4096 bytes, then by factors of 1.5 up to 128 KB, then by factors of 2 for sizes larger than 128 KB. When using jemalloc, it can also tweak allocation sizes based on dynamic information from the allocator. When smallvec adds support for custom allocators (#55) maybe that should include custom growth strategies.
I don't buy the argument that 1.5x is better, because "assuming all previous allocations are adjacent" features critically in the argument, and real allocators don't put allocations of varying sizes next to each other. 2x is simple and good.
Hi, growing the internal buffer of the vector by factor 2 is not ideal, better would be a value close to 1.5
Please read:
https://stackoverflow.com/questions/1100311/what-is-the-ideal-growth-rate-for-a-dynamically-allocated-array
The text was updated successfully, but these errors were encountered: