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.
- Though it’d also require custom containers to turn that into solution to persist containers. [↩]
- Mostly useful for storing sensitive information, such as passwords. [↩]