Path: utzoo!attcan!uunet!microsoft!earleh
From: earleh@microsoft.UUCP (Earle HORTON)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW C malloc
Message-ID: <56400@microsoft.UUCP>
Date: 8 Aug 90 06:42:36 GMT
References: <23421@dartvax.Dartmouth.EDU> <9506@goofy.Apple.COM>
Reply-To: earleh@microsoft.UUCP (Earle HORTON)
Organization: Microsoft Corp., Redmond WA
Lines: 54

In article <9506@goofy.Apple.COM> shebanow@Apple.COM (Andrew Shebanow) writes:
...
>malloc's performance is quite good, but it can have a detrimental
>effect on heap fragmentation, so you should avoid it if you also want
>to do "Mac-like" things (e.g, windows, menus, quickdraw, etc.). In
>general, I would strongly recommend against using it unless you are
>doing a straight port of a textual app - calling NewPtr is just as
>easy to write, and the storage headaches are a lot smaller (although
>the performance is, admittedly, quite a bit worse than malloc).

The source to a basic storage allocator which is very much like malloc()
may be found on pages 173-177 of "The C Programming Language" by Brian
Kernighan and Dennis M. Ritchie, Prentice-Hall Software Series, 1978.
This set of routines is comparable in performance to whatever is in the
MPW runtime libraries.  There is, however, the advantage that with source
code you have access to compile-time constants which can be used to tune
performance according to your own application's specific requirements.
Examples are: minimum amount of storage to request from the operating
system (NewPtr()) at a time, size of initial storage pool, maximum fraction
of application heap to allocate before returning failure, etc.

It is possible to implement and make use of malloc() or a similar storage
allocator in such a manner that heap fragmentation is kept to a minumum.
If you need a rather large storage pool for non-relocatable (i.e. malloc()ed)
storage in your application, then you might want to consider partitioning
your application heap into two separate storage areas.  One area would be
managed by the Macintosh Memory Manager, and the other by a simpler but
faster memory manager like the storage allocator shown in K&R.  Partitioning
the heap is simple.  Just allocate a large, non-relocatable block during the
initialization phase, and free() it so that it becomes the storage pool
used by malloc().

Note that this technique fails if the malloc() you are using ever returns
storage to the operating system via DisposPtr() or some other mechanism.
You want to maintain a large, contiguous pool of storage for use by malloc()
and free() in order to maximize the performance of these routines and also
minimize interference with "Mac-like" things.  This may not be possible
using the MPW library malloc(), but it certainly is possible using the
storage allocator from K&R, or any other storage allocator for which you
can get source code.

A little experimentation might be necessary also to determine the best
sizes for the malloc() storage pool and the Macintosh Memory Manager
storage pool (i.e. whatever is left over).  Make sure to leave enough
storage to the system for extraordinary and emergency situations, and
remember that system memory requirements can vary according to machine
model.

Disclaimers:  I don't have anything to do with Kernighan and Ritchie,
or Prentice-Hall, other than being a satisfied customer.  These opinions
are not necessarily related to any opinions that might be held by my
employer.

Earle Horton