pcraig@maths.tcd.ie (Peter Craig) (08/30/88)
In article <3435@Portia.Stanford.EDU> rick@Jessica.stanford.edu (Rick Wong) writes: >Sorry I didn't make myself clear enough. I'm programming primarily in >Object Pascal (using MacApp). Although the jump table limit may be >tractable for "traditional" languages, it is not for Object Pascal. . . . >The only real solutions to this problem have to come from Apple, or >some other development system developer (Think?). Either Object >Pascal's method dispatching needs to be redesigned so it doesn't >rely on the jump table, or the 32K jump table limit has to be lifted. Hear, hear. I find this problem extremely disconcerting. The whole point of object-oriented programming is removed if we have to start skimping on methods and inheritances. Now that someone has actually run into the problem it needs to be fixed fast, before it happens to everyone else. Having made the somewhat painful transition to MacApp (and mostly its worth it), I don't want to have to go back again. I am having a different problem with MacApp, and I need help. I have written a plot program in MacApp for plotting large numbers of different kinds of data simultaneously (i.e. overlaid). For example points, lines, images, directional information at points. MacApp is ideal for this as I can use inheritance and method redefinition to implement these different data styles 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 suspect the cause is the latter. I doubt that the Memory Manager was designed to have its memory split into a large number of very small pieces. I have no quarrel with that. Unfortunately MacApp is bound to use that kind of memory model. If I am right about this, MacApp needs a new allocation system of its very own. Anybody KNOW anything about this ? Replies should probably be by e-mail as there seems to be little interest in MacApp on this group. Thanks. Peter Craig, Dept. of Statistics, Trinity College Dublin, Ireland pcraig@maths.tcd.ie 353-1-772941 (x1203 and x2048) *** I get paid to have my own opinions ***
clive@drutx.ATT.COM (Clive Steward) (09/02/88)
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