🚀 go-pugleaf

In article <22496@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU.UUCP (David C. Navas) writes:
>In article <13920050@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes:
>>PS - I did some emperical tests, and Lattice's malloc() is significantly
>>faster than AllocMem() (in addition to being standard).  It only matters
>>if you do alot of dynamic allocation, which SKsh does.

>Does anyone else find this wierd?  I would suspect that malloc() is CALLING
>AllocMem()...  

malloc() is not a straight interface to AllocMem().  It allocates memory
in minimum 4K or so chunks (you can set the minimum allocation size with 
a global variable), and manages small allocations within the chunks on its
own.  Since it doesn't go to AllocMem() on every malloc(), it isn't all
that weird that the average speed is faster.  AllocMem() has a lot of
overhead traversing the memory lists--you can do better for lots of small 
allocations by handling a chunk of memory yourself.

There is other overhead associated with using malloc, since it allocates
some extra space to keep track of the chunks it allocated and the size
of the chunks you malloc() (which it needs for free() to work).  It also
isn't entirely standard, since Lattice malloc() deals with a possibly
(usually) non-contiguous list of memory regions, but the vast majority
of applications don't care about that sort of detail (but every now and
then you find some program that depends on some bizarre detail of the
Unix memory allocator, like the free()/realloc() behavior).

This is all specific to the Lattice implimentation of malloc().  Manx does
things differently.

-Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley)
-Wilson Lab, Cornell University