Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!ucbvax!hplabs!hpfcso!cunniff From: cunniff@hpfcso.HP.COM (Ross Cunniff) Newsgroups: comp.sys.amiga.programmer Subject: Re: Two questions about memory allocation Message-ID: <101060001@hpfcso.HP.COM> Date: 10 Jan 91 16:05:51 GMT References: <8135@ucdavis.ucdavis.edu> Organization: Hewlett-Packard, Fort Collins, CO, USA Lines: 38 In article mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) says: > Yes, it matter. Lattice does things the way Unix does - by allocating > large chunks, and using those. While testing this, I saw as much as an > order of magnitude more speed from Lattices's malloc/free than from > AllocMem/FreeMem. Manx malloc/free adds a layer around the > AllocMem/FreeMem, and so can be expected to run slower than > AllocMem/FreeMem. The advantage of Manx's way of doing things is that > free()'ed memory is given back to the system, whereas Lattice will > hang on to it until the program terminates. This causes problems in > some situations. It was for this reason that I wrote my own version of malloc(), free(), and realloc() that got fairly large (multiples of 2K? I forget) buffers via AllocMem(), handed pieces out to satisfy malloc() requests, and when all of the pieces in the chunk were free()d returned the memory to the OS via FreeMem(). This was FASTER than the standard Lattice malloc(), free(), and realloc(); however, it doesn't satisfy the Un*x requirement that free()d blocks be accessible until the next malloc(); i.e. UN*X allows the following: for( ptr = head; ptr; ptr = ptr->next ) free( ptr ); which looks at ptr->next AFTER ptr has been free()d; a real no-no if you have returned the memory to the OS. Of course, being the nice guy that I am, I don't do this :-) If Manx indeed does things the way you describe, a fair amount of ported UN*X code may show nasty, hard-to-find bugs. As I recall, the original K&R C book has an example of a malloc/free/realloc package that you could modify as I described above. >