From: "Tom Demmer" 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 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: malloc() Reply-to: Demmer AT lstm DOT ruhr-uni-bochum DOT de Message-ID: <87CD1D357B6@brain1.lstm.ruhr-uni-bochum.de> Precedence: bulk [...] > 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.