Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.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: <1991Apr9.135247.16669@ux1.cso.uiuc.edu>
Date: 9 Apr 91 13:52:47 GMT
References: <1991Apr8.101436.11202@runx.oz.au> <1991Apr8.203216.16764@ux1.cso.uiuc.edu>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 52

ml27192@uxa.cso.uiuc.edu (Mark Lanett) writes:

>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

To add some things to my previous response, I think this overhead will come with
any more-or-less generic application framework--tailoring a program to exactly
meet its needs is what you do in normal, toolbox programs. I tend to think
of this like building a car by fashioning all parts from scratch and not using
off-the-shelf "modules" (or the automotive equivalent). The car you end up with
may be better integrated than a "modular" one, but it takes a hell of a lot
or work, what you end up with isn't any good for your next car, and if you lose
track of what you're doing it may very well be a worse vehicle than the one
built out of modules. MacApp vs. the toolbox programming is like C vs assembly
language programming--most programmers can write better code than what the C
compiler does, but a C compiler can do a better job of keeping track of a 
large program than you can and will probably do a better job overall, even 
though some _parts_ of your hand-written program are much better. Given the
advent of fast processors and cheap memory, I'm hardly worried about slow
programs--a new machine will solve the problem, but hardware alone can't make
programming the Mac easier. You need this generic, modular approach to make
that work.


--
//-----------------------------------------------------------------------------
Mark Lanett						ml27192@uxa.cs.uiuc.edu