What Programmers Should Know About Memory Allocation
summary
Shows that swapping allocators changes real performance: MySQL scales differently across allocators and Firefox cuts memory by 20% reduction switching to jemalloc and another 16% with mesh. Measures allocation/free pair costs from ~50 ns down to 17 ns with thread caches. Demonstrates pathological cases: producer→consumer frees cause 1.4 μs per item due to ownership transfer, and a 16M-node linked list shows huge cache-line differences between slab and bump-pointer placement. Recommends using allocator hooks, arenas, region allocators, and measured tests in production-like environments.
AI-written summary · about
chapters (23)
- 0:00Introduction to memory allocation
- 3:17Challenges in allocator design
- 7:14Fragmentation and compaction
- 8:18Multi-core scaling issues
- 11:51Validation in production
- 13:19Security and memory errors
- 15:45Common allocator design patterns
- 20:58Anti-patterns in allocation
- 22:26Segregated free lists
- 25:37Slab allocations explained
- 28:49Optimizing access patterns
- 30:14Growing memory regions correctly
- 32:23Detecting fragmentation
- 35:10TLB and memory locality
- 38:01Allocator bleed in multi-threaded apps
- 41:50Arena management and wasted memory
- 43:20Non-uniform memory access
- 45:51OS memory boundaries
- 47:15Overcommit in operating systems
- 49:41Debugging memory allocators
- 54:23Custom allocators: pros and cons
- 56:52Region allocators and use cases
- 58:57Q&A session
related talks
01h 02mPractical Memory Pool Based Allocators For Modern C++
01h 04mWe Live in Interesting Times
57m“An allocator model for std2”
42mAdventures in Efficiency and Performance
56mWhy Data Access Patterns Have Always Mattered
01h 03mAn Allocator is a Handle to a Heap
27mThe Mutability Matrix of Pain
51mDesigning for Performance