Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!ucsd!chem.ucsd.edu!tps
From: tps@chem.ucsd.edu (Tom Stockfisch)
Newsgroups: comp.lang.c
Subject: Re: Memory Allocation (was Re: binary data files)
Message-ID: <461@chem.ucsd.EDU>
Date: 4 May 89 08:04:03 GMT
References: <10946@bloom-beacon.MIT.EDU> <12546@ut-emx.UUCP> <29978@apple.Apple.COM> <17252@mimsy.UUCP> <1989May3.201118.10221@utzoo.uucp> <10202@smoke.BRL.MIL>
Reply-To: tps@chem.ucsd.edu (Tom Stockfisch)
Organization: Chemistry Dept, UC San Diego
Lines: 23

In article <10202@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <1989May3.201118.10221@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>In article <17252@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>>I get the feeling that some future BSD will have six different malloc
>>>library routines. . . .
>>It would be too much to ask for one *good* one!  :-) :-(

>Most applications that really care about malloc() efficiency have already
>given up and implemented their own technique, using malloc() simply as an
>sbrk() surrogate.

The problem is that a power-of-2 malloc()/realloc() cannot be
regarded as an sbrk() surrogate when considering the
problem of constructing a potentially
long object whose size is it not known until
you are done constructing it.

You waste up to a factor of 4 with a power-of-2 implementation,
not including fragmentation.

-- 

|| Tom Stockfisch, UCSD Chemistry	tps@chem.ucsd.edu