is GNU malloc/free really slow?

is GNU malloc/free really slow?

Post by John E. Stu » Thu, 07 Jul 1994 07:11:31



I have an application that builds a large hash table of keys and values.
It makes heavy use of malloc(). On an ESIX platform (i486, SVR4) the time
it takes to build this table is a split second, but on Linux (i486, Slackware
1.1.2) it takes almost 10 seconds. When deleting the table by free()ing
all the memory takes again a split second on ESIX but ~8 seconds on Linux.
This speed is not acceptable in my application.

Is there any method to speed up the performance of GNU's dynamic memory
routines? Any replacement libraries?

Thanks for any help or guidance.

john

--

 
 
 

is GNU malloc/free really slow?

Post by David Parkins » Thu, 07 Jul 1994 21:25:06


Please excuse the post but email got nowhere!


: I have an application that builds a large hash table of keys and values.
: It makes heavy use of malloc(). On an ESIX platform (i486, SVR4) the time
: it takes to build this table is a split second, but on Linux (i486, Slackware
: 1.1.2) it takes almost 10 seconds. When deleting the table by free()ing
: all the memory takes again a split second on ESIX but ~8 seconds on Linux.
: This speed is not acceptable in my application.

: Is there any method to speed up the performance of GNU's dynamic memory
: routines? Any replacement libraries?

: Thanks for any help or guidance.

: john

John,

Just a thought which might help you....

Having worked in the past in memory limited situations I've always been
irritated with the overheads of malloc() and free() - especially if
they're being used to build tables where each entry is quite small.
(e.g. 8-10 bytes for the entry, possibly 8 bytes or more of malloc()
overhead).

My approach now is to use an intermediate function - say alloc().
alloc() initially calls malloc() to get a large chunk of memory.
Thereafter, on every call to it, it allocates the requested # of
bytes from its own pool, adjusting the 'output' pointer appropriately.
It maintains no management info and therefore does not support a
free() or realloc() function.  (A simple extension will support free()
and realloc() on just the last call).

It's quick, has minimal overhead, and if necessary a single call to free()
can be used at the end to free up the table space when you've finished
with it.

It works best with fixed sized tables, but once again the approach can
be extended so that for say 5,000 calls to alloc() you might end up
doing 3 calls to malloc().

Regards

david