From: Paul Shirley <Paul AT no DOT spam DOT please>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: mem alloc taking up power of 2
Date: Fri, 18 Jul 1997 19:55:44 +0100
Organization: wot? me?
Distribution: world
Message-ID: <foUFZCAww7zzEwdz@foobar.co.uk>
References: <33cc4f06 DOT 4823733 AT 192 DOT 189 DOT 54 DOT 145>
 <vlnYdGAm+QzzEwqo AT talula DOT demon DOT co DOT uk>
Reply-To: Paul Shirley <Paul AT chocolat DOT obvious DOT fake DOT foobar DOT co DOT uk>
NNTP-Posting-Host: chocolat.foobar.co.uk
Mime-Version: 1.0
Lines: 23
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

In article <vlnYdGAm+QzzEwqo AT talula DOT demon DOT co DOT uk>, Shawn Hargreaves
<Shawn AT talula DOT demon DOT co DOT uk> writes
>You could replace the libc malloc with one that uses a different
>algorithm, like the one I'm attaching to the end of this message. But it
>isn't really such a great problem. When you say that you are losing
>640k, remember that this is virtual memory, so if you never touch the
>space the DPMI server won't actually bother to allocate any hardware
>pages for it. The only thing being wasted is a few meg of your 32 bit
>linear address space, but there's plenty of that to go around :-)

There's also the common situation of allocating large numbers of small
blocks with malloc. If you use less than the VM page size then that
memory really will be wasted (4K/page last time I looked).

The built in malloc is *extremely* fast, only replace it if you expect
to use lots of small blocks. Even then you should probably attempt to
allocate large blocks with malloc and subdivide them with custom
allocators.


---
Visit www.dukepsx.com: see what I do all day.
Paul Shirley: my email address is 'obvious'ly anti-spammed