From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: malloc()
Date: Fri, 31 Oct 1997 09:26:05 +0100
Organization: University of Ghent, Belgium
Message-ID: <3459961D.500F@rug.ac.be>
References: <199710302300 DOT KAA01562 AT mona DOT lexicon DOT net DOT au>
NNTP-Posting-Host: eduserv1.rug.ac.be
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 30
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

I want to add the following 2 things:

1.
The current malloc implementation wastes linear memory at a high rate,
but it does not do so for physical memory. Whether this linear memory
wastage has significant disadvantages depends largely on the
capabilities of the DPMI host. If that host allocates (physical-disk)
swap space for the wasted blocks, and I think most hosts do because this
is much easier to implement, linear memory may become very fast full.
This may especially become significant on systems with small hard disks.

2.
A single constant number cannot be "the" result from a speed comparison.
The results based on a single (non-realistic) test, that Doug Lea's
malloc takes about 7 times more cycles than the currently used BSD's is
not very meaningful (and maybe even not indicative).
To have a good comparison, at least, you should use malloc in a program
that allocates, frees and reallocates memory, and measure time
differences. I think a good choice would be the GNU C compiler with a
modestly large source file, but there may be others programs that are
also representative.
A regular program doesn't allocate memory in totally random chunks, nor
does it allocate all memory linearly.


-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/