Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.tech Subject: Re: A REAL fork() function (was Re: SKsh weirdness) Message-ID: <9902@cbmvax.commodore.com> Date: 1 Mar 90 02:44:54 GMT References: <13920050@hpfelg.HP.COM> <22496@pasteur.Berkeley.EDU> Reply-To: daveh@cbmvax.cbm.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 32 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