5

I have very high performance C++ library. I am thinking of writing a memory pool so that I do not have to use global new and delete. I did some reading. But wanted to know will this help me in performance and memory leaks reduction.

Avinash
  • 12,851
  • 32
  • 116
  • 186
  • 3
    Are you 100% sure that new and delete are a bottleneck in your code ? Have you profiled ? – Paul R Jan 07 '13 at 07:11
  • 1
    http://www.boost.org/doc/libs/1_43_0/libs/pool/doc/index.html – ta.speot.is Jan 07 '13 at 07:15
  • Performance: if your library has a peculiar allocation pattern, you might save time by writing an allocator that's specialised to deal with your library. Memory leaks: unless you run some sort of garbage collector, it won't make a difference. –  Jan 07 '13 at 07:16
  • also - afaik *some* boost structs (e.g. regex) do not support custom allocators. Make sure all your structs support this before diving too deep into it. – OSH Jan 07 '13 at 07:21

3 Answers3

2

Unless you have a very specific reason to believe that your library will benefit from a custom allocator, chances are that it will probably not help much, if at all.

It sounds like you're trying to perform undirected optimization. Don't. Use profiling to gather performance data first, then consider optimizing, if appropriate.

1

A memory allocator that is fine tuned to the exact memory allocation pattern of your application should outperform any generic allocator -- given that your allocation patterns differ from "generic" and are predictable. However, the memory leak reduction or detection is a completely different issue and should be resolved before any concerns in performance.

Aki Suihkonen
  • 19,144
  • 1
  • 36
  • 57
0

According to my experience, implementing your own memory pool does't help performance. Because in multithreaded environment you have to use mutex to protect memory alloc and free upon the pool, while mutex is very heavy comparing to system new/delete.

Also it doesn't help reduce memory leak. To reduce memory leak, you must make sure to free all memory that you have allocated. It should really be solved with your program rather than a pool.

The only benefit might be helping trace memory usage independent on third party tool.

TieDad
  • 9,143
  • 5
  • 32
  • 58
  • What about userspace/lightweight threads? –  Jan 07 '13 at 07:21
  • 1
    You don't actually have to use a mutex, this is just one particular implementation that you happened to encounter. You could perfectly use a per-thread pool or non-blocking atomics or whatever. – Matthieu M. Jan 07 '13 at 07:40
  • 'memory' is a bit general. If the 'memory' is actually a pool of objects with non-trivial ctors/dtors, the pool can be faster, even with some mutex/futex protection. – Martin James Jan 07 '13 at 09:49