CppCon 2017: John Lakos “Local ('Arena') Memory Allocators (part 1 of 2)”

CppCon · 95K views · 2017 · 1:00:05

Open on YouTube

C, C++, Rust, Go & systems languagesSoftware performance & optimizationtalk

Why Stack Overflow recommends it

Stack Overflow users link it when answering questions about custom allocators, cache locality and allocating data structures like trees and containers efficiently.

Recommended by 3 people across 3 different months, 2011 to 2021.

What it is

A CppCon 2017 talk (part 1 of 2) by John Lakos on local, or arena, memory allocators in C++. It explains how global new/delete and std::allocator can degrade performance and how local allocators can give order-of-magnitude speedups, introducing six dimensions for choosing one.

What people said

Recommends ppetraki · 2017-10 · Stack Overflow · on “dynamically sized classes in c++”

The pointers aren't your problem, it's the lack of cache hits from having one object allocated over here and another one allocated elsewhere on the heap for the actual string. If you could allocate it all consecutively you would be in optimal cache hit territory. I know you said no trees but if you wrote a custom allocator and plugged it into std::map or std::set you could achieve this functionality. You should check out the cppcon talk on arena allocators. "CppCon 2017: John Lakos “Local ('Arena') Memory Allocators” [this video] [LINK] A "simpler" way to achieve this is to maintain two vectors, for Word and a "insert chunk aligned vector for allocating range for LetterData" respectively. Word wo

Recommends Jérôme Richard · 2021-04 · Stack Overflow · on “Implement tree structure. Store nodes in vector and denote children with indices? Or store nodes on the heap and use pointers to the children?”

The standard efficient C++ way of doing that is to write your data structure without worrying about how data are allocated, and use a dedicated allocator template parameter (like std::vector or std::map ). This method helps to keep your code maintainable (thanks to separation of concerns ) and be still quite efficient (thanks to templates). With this solution, you can first write your code easily (with the approach n°1) and then optimize allocations easily too (using for example the approach n°2). Regarding the optimization of allocation: yes, new & delete could be slow (despite some platforms do this very efficiently). Since there are no node deleted, you can use a very fast monotonic arena

Recommends Sebastian Hoffmann · 2021-10 · Stack Overflow · on “Should classes manage dynamic memory on their own?”

`For instance, it would be quite trivial to make a 'fake' allocator that just passes stack memory to an object which would, under normal circumstances, require dynamic memory,` Actually people do this and cpp/std has been specifically designed to support use cases like these. Thats indeed one application where allocators come in handy. If you're interested in allocators I recommend [this video]

Cites Marc Mutz - mmutz · 2011-05 · Stack Overflow · on “STL or Qt containers?”

The Qt containers are more limited than the STL ones. A few examples of where the STL ones are superior (all of these I have hit in the past): STL is standardized, doesn't change with every Qt version (Qt 2 had QList [LINK] (pointer-based) and QValueList [LINK] (value-based); Qt 3 had QPtrList and QValueList ; Qt 4 now has QList , and it's nothing at all like QPtrList or QValueList ). Qt 6 will have a QList that's QVector while QVector will be deprecated . Even if you end up using the Qt containers, use the STL-compatible API subset (ie. push_back() , not append() ; front() , not first() , ...) to avoid porting yet again come Qt 6. In both Qt2->3 and Qt3->4 transitions, the changes in the Qt