Path: utzoo!utgpu!water!watmath!clyde!att!mtuxo!mtgzz!drutx!clive
From: clive@drutx.ATT.COM (Clive Steward)
Newsgroups: comp.sys.mac.programmer
Subject: Re: 32K jump table limit; MacApp memory problem
Message-ID: <8608@drutx.ATT.COM>
Date: 1 Sep 88 18:41:37 GMT
References: <41@maths.tcd.ie>
Organization: resident visitor
Lines: 37

From article <41@maths.tcd.ie>, by pcraig@maths.tcd.ie (Peter Craig):
> in a common framework. The problem is that there can be as many as 100,000 
> of these points, etc. to be plotted, and hence there may be as many as
> 100,000 objects each of which is a relocatable area of memory which has
> a master pointer. The Macintosh Memory manager does not appear to be
> able to cope with this. I have lots of memory. I know that there is
> no need for memory compaction. Profiling the application indicates that
> it spends most of its time doing memory compaction. The result is that
> it can take several minutes for a mouse-down in the menu-bar to have any 
> effect. Can someone please tell me why this is happening. Is it MacApp or
> the Memory Manager  ?
> 
I don't know just what it is, but ran into this same problem with 
C programs which also needed lots of memory managing of small items.

Under LSC, I re-wrote the malloc and calloc calls to use a chunking
scheme -- not to call NewPtr except once in a while for largish hunk,
usually 2k or so.  This worked fine -- order of 100 times speedup for
these programs.

I notice now that I use it, that MPW C's malloc call is said to do
the same thing.

Don't know about MacApp, or why even that NewPtr doesn't chunk itself;
it would seem to have been sensible for the basic Mac to do it this
way, but maybe not in 64k Rom or something.

Anyway, as an interim measure, why not just write a memory manager to
sit on top of MacApp's.  If you're in Pascal, surely you could still
use Kernighan and Ritchie's C book as a ref -- the malloc () with 
morecore () routine is basically what I used, with an upped chunk size.


Good luck --


Clive Steward