From:	"Tom Demmer" <DEMMER AT brain1 DOT lstm DOT ruhr-uni-bochum DOT de>
Organization:	Lehrstuhl Stroemungsmechanik, RUB
To:	sandmann AT clio DOT rice DOT edu (Charles Sandmann), djgpp-workers AT delorie DOT com
Date:	Sun, 9 Nov 1997 20:20:48 GMT-1
MIME-Version:	1.0
Subject:	Re: malloc()
Reply-to:	Demmer AT lstm DOT ruhr-uni-bochum DOT de
Message-ID:	<87CD1D357B6@brain1.lstm.ruhr-uni-bochum.de>

[...]
> In any case, the person who does the testing must ultimately convince
> DJ the code is stable, meets the copyright requirements, and has been
> adequately tested.  
> 
For the copyright issue:
The code _is_absolutely_free_. No GPL, just free.
Stability:
The docs make me think that it hes been used in a wide range of 
applications and thoroughly tested. It looks as if the author knew 
what he is doing. The only reason I could think of not using the 
package from a stabilty point of view is that sbrk() under DJGPP may 
behave quite differently from the UNIX behavior. I have tested it 
with the default sbrk() algorithm and it is just as broken as the 
normal malloc(), in so far as it tends to kill my Netware connection 
when running out of space. This is probably due to my NW setup ;-)

In terms of speed, it tends to be slower than the libc malloc, if one 
looks only at the allocator/deallocator. The factor is about 2, not 
as SET reported, 7. Things change when not only malloc but also 
realloc is used, because this sometimes means touching the data as 
well. Also, when using memset() to touch the data, the libc malloc is 
never faster. 

The next test I performed was allocating fixed size blocks until 
malloc ran out of memory. The libc malloc can allocate more blocks 
when the blocksize is < 8, otherwise the new one can supply more or 
the same amount. 

The tests were run on a 16 MB DX4/100, I will cross check them on a 
Pentium. Swapping was avoided. Eli proposed to set the CWSDPMI swap 
file to a nonexistent drive to figure out when swapping occurs. Can't 
the same be archived by just setting __CRT0_LOCK_MEMORY?

One last thing, the tests produce some files with blocksize-time 
columns, is it OK to post them here or will I get beaten to death?
There a some 300 lines of figures...

Ciao
Tom

  ******************************************************************
  *  Thomas Demmer                     * Phone : +49 234 700 6434  *
  *  Universitaetsstr. 150             * Fax   : +49 234 709 4162  *
  *  Lehrstuhl fuer Stroemungsmechanik *                           *
  *  D-44780 Bochum                    *                           *
  ******************************************************************
  *  Email: demmer AT LStM DOT Ruhr-Uni-Bochum DOT De                         *
  *  WWW:   http://www.lstm.ruhr-uni-bochum.de/~demmer             *
  ******************************************************************

    Ablaza's Observation: Every machine will eventually fall apart.

- Raw text -