Message-Id: <199710301211.XAA08637@mona.lexicon.net.au>
Comments: Authenticated sender is <sjmachin AT mail DOT lexicon DOT net DOT au>
From: "John Machin" <sjmachin AT lexicon DOT net DOT au>
To: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>, djgpp AT delorie DOT com
Date: Thu, 30 Oct 1997 23:09:39 +1000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: malloc()
In-reply-to: <m0xQAl6-000S1oC@inti.gov.ar>
Precedence: bulk

> From:          "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
> To:            "John Machin" <sjmachin AT lexicon DOT net DOT au>, djgpp AT delorie DOT com
> Date:          Tue, 28 Oct 1997 15:33:52 +0000
> Subject:       Re: malloc()

> "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.

Oh. I thought if you allocated a page of memory (4096 bytes) and 
touched only the first byte then it was all mapped ... what is the 
unit of mapping???

> 
> > 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.

Speed is not the only consideration. Robustness in the face of varied 
patterns of malloc/free requests may be another consideration for 
some ... Allocators which don't split/coalesce free blocks can break 
down if the program allocates a large number of blocks of size x, 
frees them, allocates/frees ditto sizes y,z, etc (where x,y,z etc 
belong in different power-of-two buckets) --- unrealistic? No, e.g. 
program == text editor, x == average len of source file line, y == 
average len of record in data file1,...

> 
> > 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.
> 

Like I said, "the first few lines of the source file".

John Machin
1/27 Auburn Grove
Hawthorn East, VIC 3123, Australia
Phone: +61-3-98130561