UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

  • Index
  • » C++
  • » Runtime overhead of malloc() and free()?

#1 2007-09-21 11:17 PM

jfriesne
Administrator
From: California
Registered: 2005-07-06
Posts: 348
Website

Re: Runtime overhead of malloc() and free()?

Hi All,

I'm curious as to what the run-time overhead of malloc() and free() (and by extension, new and delete) is in modern/common operating systems.   That is to say, if I malloc() a buffer of N bytes, how many bytes of RAM will actually be allocated under MacOS, Linux, and Windows?  I know there will be some additional bytes allocated behind the scenes for "housekeeping", but how many?  Also, how expensive are these calls in terms of CPU cycles?

The reason I ask is because I'm working on some object-pooling code which will pre-allocate an array of (small, commonly used) C++ objects in advance and dole them out as needed, thus avoiding having to do a separate new or delete for each little object.  My current pool implementation adds a memory overhead of 8 bytes per object (for "owner-slab" and "next object" pointers in the pool's free-list), and CPU overhead of locking a mutex, changing a few pointers around, and unlocking it again.  OTOH, if that's not significantly better than what modern (clever) versions of malloc() and free() cost, then I'm just re-inventing the wheel and probably shouldn't bother.

Offline

#2 2007-09-21 11:53 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Runtime overhead of malloc() and free()?

The cost is relatively high.

That said, it is optimised to death, so it's very hard to do better manually.

Unix systems use virtual memory and often don't allocate physical RAM
until you actually use the memory. As for the overhead, the malloc overhead
is not more than 8 bytes I think, probably 4. But the minimum chunk size
might be bigger than you need, so memory can be wasted on internal
fragmentation too.

It only makes sense to do your manual memory handling if it's really needed
and has measurable advantages. So in practice that means that you only need to
allocate a limited set of fixed size objects which you know beforehand, because
making a memory allocator for those is much simple and slightly faster than a
generic malloc implementation which needs to handle variable sized memory
chunks. You also should measure the performance difference to see if it actually
helps anything. Or better yet, profile the code to see if implementing it makes
sense in the first place.

Offline

#3 2007-09-22 02:01 AM

jfriesne
Administrator
From: California
Registered: 2005-07-06
Posts: 348
Website

Re: Runtime overhead of malloc() and free()?

Hmmm... a torture test of my slab allocator code (under SUSE 10) seems to bear this out, at least as far as memory usage goes:  my test allocates 10 million small objects, and it doesn't matter whether each object is allocated with a separate call to new, or they are allocated in absurdly large multi-thousand-object slabs, or slab size  in between... the final memory usage of the process (as reported by ps) remains almost exactly the same.  That suggests that malloc() and my code have the same memory overhead per object.

That said, the slab-allocator version does finish the task about 28% faster than calling new separately for each item.  So there is some CPU advantage to be had.

Thanks for the advice i3839!

-Jeremy

Offline

  • Index
  • » C++
  • » Runtime overhead of malloc() and free()?

Board footer

Powered by FluxBB