Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <34698C84.69EA@rug.ac.be>
Date: Wed, 12 Nov 1997 12:01:24 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: Demmer AT lstm DOT ruhr-uni-bochum DOT de
Cc: djgpp-workers AT delorie DOT com
Subject: Re: malloc()
References: <87CD1D357B6 AT brain1 DOT lstm DOT ruhr-uni-bochum DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Tom Demmer wrote:

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

There is more to it than only the malloc, realloc and free functions. An
average program doesn't spend much time allocating and deallocating, so
overall performance may even not change at all.

Criteria for a good allocator are, IMHO, AFAIK, IIRC:
- It shouldn't waste memory (or rely on the DPMI host that it catches
this)
This includes the use of an excessive amount of adminstrative data for
allocated blocks.
- Memory fragmentation should be avoided (this is especially important
for programs that run for a longer time like many interactive programs
(and OSes), but I think also about 'make'). A general malloc
implementation should meet these programs.
- Blocks allocated at the same time, should be allocated 'close'
together, although that rule is mutually exclusive with the previous on
many occasions.
- The ability to return freed memory to the system (in case of djgpp I
think this is next to impossible because of the linearity of the memory
and the possibility by other functions than malloc to call brk/sbrk)
- Exploiting platform specific benefits, like allocating on 32 byte
addresses for PII machines or allocating on 16 byte addresses for
Pentiums. The current implementation allocates on 4K page boundaries,
and that's fine as long as it doesn't waste memory.

Non-criteria are:
- The speed (except exponential increase)
- The ability to fastly realloc memory (but it may be an advantage
though)

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