Measuring C++ Allocator Performance

So after all these pretty graphs and numbers, what’s the verdict? Does it make sense to use custom allocators in naive usage scenarios?

Well, yes and no. The absolute performance gains over the test runs, which perform a decent amount of allocations and frees, isn’t very large at all. If you’re writing software that’s processing large amounts of data, though, a custom allocator may help improve it’s performance. I’m still certain that a good choice of data structures or algorithm helps a lot more, though.

But that doesn’t mean the allocator code in fhtagn! is entirely wasted. The infrastructure of a an allocator with pluggable allocation policies, and a pool allocation policy that delegates to a C-Style malloc/free interface may still come in handy. It should be trivial, for example, to whip up an allocator that draws memory from a memory mapped file1, or from memory pages that the system is not allowed to swap out2. And start fhtagn!’s code makes certainly beats writing everything from scratch again.

  1. Though it’d also require custom containers to turn that into solution to persist containers. []
  2. Mostly useful for storing sensitive information, such as passwords. []

Pages: 1 2 3 4 5

Comments are closed.


Copyright © 2007 - 2017 by the respective authors.
Permission to use the image of Great Cthulhu has kindly been granted by F. Launet/Goomi Studio.
Other content on this website is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.0 Germany License.
Creative Commons License


Blog directory