philipc@runx.oz.au (Philip Craig) (04/08/91)
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. *Please* e-mail me any replies, as I get mail three (3!) weeks faster than I get news items. I will summarize the results to the net. Thanks in advance, -- | Philip Craig | ACSnet,Ean,CSnet: philipc@runxtsa.runx.oz.au | | RUNX Unix Timeshare | Arpa: philipc%runxtsa.runx.oz.au@UUNET.UU.NET | | Wahroonga NSW 2076 | Janet: philipc%runxtsa.runx.oz.au@UK.AC.UKC | | Australia | UUCP:{uunet,mcvax}!munnari!runxtsa.runx.oz.au!philipc|
ml27192@uxa.cso.uiuc.edu (Mark Lanett) (04/09/91)
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
ml27192@uxa.cso.uiuc.edu (Mark Lanett) (04/09/91)
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
keith@Apple.COM (Keith Rollin) (04/10/91)
In article <1991Apr8.203216.16764@ux1.cso.uiuc.edu> ml27192@uxa.cso.uiuc.edu (Mark Lanett) writes: > >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. No, I don't think that Apple is lying when we claim that MacApp programs aren't slower. A properly written MacApp program runs just fine. It's just that with any large, complex system -- such as MacApp -- you have to keep optimization issues in mind. There's a reason why MacApp is so large: it does a lot. If a program does a lot, it will naturaly take a long time to do it. The trick is to make sure that you don't require MacApp to do everything it can do every time through your main event loop. Resizing a window is a good example of putting MacApp through its paces. In a complex windows, each view has to get a crack at what it needs to to. Doing a full traversal of the views will take a while. (This will be better in MacApp 3.0, by the way). However, you aren't resizing your windows every time through the main event loop, so that aspect of MacApp shouldn't be slowing down your program. And if you stay away from things like full view traversals where you have to call TView.Focus on each view, you should be fine. Most of MacApp's code deals with user interface issues. As such, it percentage of execution is only about 10-20% of any complex program. If you reduce this percentage, and/or concentrate on the other 80-90%, then you'll probably starts to get the big wins. >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. Good point. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
murat@farcomp.UUCP (Murat Konar) (04/13/91)
>Resizing a window is a good example of putting MacApp through its >paces. In a complex windows, each view has to get a crack at what it >needs to to. Doing a full traversal of the views will take a while. >(This will be better in MacApp 3.0, by the way). On a project I'm working on now, we gave up trying to use a view hierarchy all together. Our main window has a single view inside a scroller. After that it's classic ToolBox stuff. I suspect that another reason for speed problems in MacApp may be due to heavy use of TLists everywhere. I haven't looked into this too deeply so I may be wrong. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com