Message-Id: <m0xQAl6-000S1oC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
Organization: INTI
To: "John Machin" <sjmachin AT lexicon DOT net DOT au>, djgpp AT delorie DOT com
Date: Tue, 28 Oct 1997 15:33:52 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: malloc()
Precedence: bulk

"John Machin" <sjmachin AT lexicon DOT net DOT au> wrote:

> As mentioned in some discussions in this list, and in the
> comments in malloc.c, the algorithm that is used allocates (or is
> supposed to allocate) blocks of size 2^n. Of this, 4 bytes are
> overhead. So a malloc(2044) -> 2048-byte block, malloc(2045) ->
> 4096-byte block, etc. This means (approximately) an overhead of 0%
> to 100% on the requested size, or a waste of 0% to 50% of the memory
> grabbed.
> 
> HOWEVER, experimental results, confirmed by reading the source, show
> that the simplistic algorithm has been twiddled for request sizes
> over 2044 bytes so that it skews the world by 4096 bytes. The
> results are:
[snipped values] 
You are missing something: If you have enough swap it doesn't matter because 
the memory that you allocate and don't touch just wastes virtual memory but is 
well remaped by the DPMI host so your % aren't true. Is hard to say the real 
waste.
 
> This could be fixed, but I am puzzled why DJ hasn't snarfed a better
> malloc from somewhere -- I understand his comments about GNU GPL
> that he made in a posting, but what about public-domain stuff???
Eli pointed why and I'll point an additional thing:
DJGPP's malloc is HYPER fast. I know how it works (I even modified it) and I 
know how the Borland's one works (I have the sources) and beleive me, in a 
program that uses heavilly the heap the DJGPP's version is much, MUCH more 
faster.
 
> Pardon me if this has been considered and rejected it for 
> reasons that I can't guess, but I'd suggest that "Doug Lea's malloc" 
> would be a good substitute. I got it off the web, whacked in a few 
> #defines, compiled it, and happiness prevailed; see below which is 
> the first few lines of the source file with my changes and his 
> "advertisement" and URLs.

I got just a portion of the file.

SET
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013