Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!uwm.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!ml27192
From: ml27192@uxa.cso.uiuc.edu (Mark Lanett)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Speeding up MacApp programs
Message-ID: <1991Apr8.203216.16764@ux1.cso.uiuc.edu>
Date: 8 Apr 91 20:32:16 GMT
References: <1991Apr8.101436.11202@runx.oz.au>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 27

philipc@runx.oz.au (Philip Craig) writes:

>Greetings netters,
>	I am soon to be having a look at a MacApp-based project that runs
>very slowly, too slowly in fact to take to market as is. I was wondering
>if people here have any suggestions or brilliant ideas as to how to speed
>up MacApp code in large projects. I have an idea that the speed bottleneck
>is due to many (thousands?) of small objects being continually allocated and
>deallocated, but I'd be interested to see what other speed-up ideas people
>have.

I don't pay much attention to speed, but even on an FX it's obvious that Apple
it lying when it claims that MacApp programs aren't slower. MacApp spends a
lot of time just running through its command chain. It's not that it's
object-oriented, but that the hierarchy of objects -- especially view objects
-- causes it to have to make _lots_ of calls just to resize a window. I think
there's not much to be done here--you could write one big subclass of a view
object and switch on it like before, but there's still the normal MacApp
overhead to go through.

I concentrate on user-interface design to achieve speed-ups; i.e. if you have
some search that uses a modal dialog box, making it modeless will appear to
speed things for the user more than a faster search would (most of the time);
using popup menus instead of dialog boxes altogether is one of the best ways.
--
//-----------------------------------------------------------------------------
Mark Lanett						ml27192@uxa.cs.uiuc.edu