views:

58

answers:

2

Want to explore few memory managers for our product - boost, small object allocator as in loki and one memory manager available internally in our company.

Before choosing one for our product, we want to explore all options with small prototype application which need not be similar to our application in terms of functionality. My objective is to analyze performance and peak VM for same number of allocation and deallocation of objects of various size - contiguous and non-contiguous. It's should work with std containers or boost libraries.

Any idea how to go for such prototype application? Our application is not MT - but in future we've plans for it. Any suggestion would be a great help. Having so called randomness in terms of object allocation like a real application would be great.

Also, suggesting some other memory manager available in public domain would be of great help.We're primarily on Linux 32b and 64b.

A: 

We added a small object allocator based on boost to our system in under 2 hours. It's really that simple to get it in place as long as you have access to your own malloc/new stuff. Then you can measure against your own project.

Failing that, profile your apps memory usage footprint - say have it print out / log all memory allocations into a file for a few minutes or to a size and then take that log and make a new app that just does these allocations and frees (with and without the small object allocator) - and perhaps counts prime numbers or something between allocs to simulate cache misses.

Michael Dorgan
+1  A: 

This is an odd question. You should only ever consider a custom memory allocator if you try to solve a very specific problem with the one that's built into your CRT. Which should offer an immediate approach to testing this alternate allocator: see if it solves that problem.

If you are only doing this because it "sounds like a good idea", then don't. It isn't. The one built into the CRT is already heavily optimized.

Hans Passant