Loading...
[-]

Custom memory allocators in C++

Custom memory allocators are becoming more and more marginalized as general ones improve. While in the past programmers faced with problems such as the low performance allocators in the STL might have considered writing their own, today we can simply use EA’s eastl::allocator and address most of the problems. Time is usually better spent on developing your core business functionality rather than on writing memory allocators. Here’s an interesting paper on the subject which compares the performance of general purpose allocators against custom ones:

Reconsidering Custom Memory Allocation

Emery D. Berger
Benjamin G. Zorn
Kathryn S. McKinley

Abstract
Programmers hoping to achieve performance improvements often use custom memory allocators. This in-depth study examines eight applications that use custom allocators. Surprisingly, for six of these applications, a state-of-the-art general-purpose allocator (the Lea allocator) performs as well as or better than the custom allocators. The two exceptions use regions, which deliver higher performance (improvements of up to 44%). Regions also reduce programmer burden and eliminate a source of memory leaks. However, we show that the inability of programmers to free individual objects within regions can lead to a substantial increase in memory consumption. Worse, this limitation precludes the use of regions in common programming idioms, reducing their usefulness.
   We present a generalization of general-purpose and region-based allocators that we call reaps. Reaps are a combination of regions and heaps, providing a full range of region semantics with the addition of individual object deletion. We show that our implementation of reaps provides high performance, outperforming other allocators with region-like semantics. Our results indicate that programmers needing fast regions should use reaps, and that most programmers considering custom allocators should instead use the Lea allocator.

pp9-10

Drift.
In at least one case, we suspect that programmers initially made the right decision in choosing to use custom allocation for performance, but that their software evolved and the custom allocator no longer has a performance impact.

Complete Paper (PDF 0.3MB)

Post a Comment

Your email is never shared. Required fields are marked *

*
*