🚀 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()...  

While it sounds weird at first, it may not be quite that weird.  A good 
implementation of malloc() probably won't call AllocMem() for every little
allocation.  I have an allocation routine in the DiskSalv code wich works
this way.  It maintains memory lists of its own, calling AllocMem() and
making a new memory list only when there's insufficient memory already
allocated.  This could certainly waste memory over lots of individual calls
to AllocMem(), but it has a few advantages.  First of all, it eliminates
the need to track dynamic objects; you have just one FreeMem() call, which
removes the memory list, and thus, everything handed out from that list.
You also don't fragment system memory this way, even if you like to 
dynamically allocate thousands of little strings.  Secondly, AllocMem() has 
to do its work inside Forbid(), so that other tasks can't muck with 
system-wide memory lists.  So it is certainly possible that Lattice's 
malloc() runs faster, over multiple allocations, than AllocMem().

>David Navas                                   navas@cory.berkeley.edu
>"Think you can, think you can't -- either way it's true."  Henry Ford


-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough