Morphic slowness (was Re: Does *anyone* use MVC?)

Andreas Raab Andreas.Raab at gmx.de
Thu Aug 1 23:29:35 UTC 2002


Ned,

> Here's what I tried on my WinCE machine (131MHz MIPS).
> 
> It takes 4.2 seconds to open the World Menu
> (and about 1 second to see characters that I type into a Workspace!).

Boy, this sucks...

> 1.9 seconds is spent doing layout with a TableLayout
> (which is probably overkill for a MenuMorph anyway).
> (I suspect that the layout is happening each time that a menu item
> is being added).

Ah, yes. My "favourite" morphic inefficiency. The problem is that Morphs
dump their fullBounds (e.g., the rectangle describing the composite
bounds of the morph and its submorphs) to indicate that they need a new
layout but naturally, for correct invalidation the full bounds are just
what we absolutely need! So whenever we invalidate a morph which needs a
new layout we will end up with:

44.8% {1909ms} PasteUpMorph(Morph)>>addedOrRemovedSubmorph:
	44.8% {1909ms} MenuMorph(Morph)>>fullBounds
		44.8% {1909ms} MenuMorph(Morph)>>doLayoutIn:

> 0.5 seconds is spent setting up BalloonTexts, most of this in
> truncating Strings (!)

Which could probably be handled by just using the #balloonTextSelector
to construct the balloon help dynamically (hey, that's what it's good
for ;-)

> 0.5 seconds is spent on getting the pushpin image for the
> titlebar. I need to cache that...

Probably so ;-)

> And, though I don't see where it's happening,
> 
> 1.3 seconds is spent looking through IdentityDictionaries.
> Presumably this is looking for Morph properties and preferences.

Very likely, although I wouldn't bother too much about it at this point.
If you can fix some of the other problems the tallies will show much
clearer where the time is spent.

> So what would you attack first?

Balloon help and pin-form. Both of them have obvious solutions.

> I'd first see if I couldn't dispense with the TableLayout in 
> the MenuMorphs.

You could try that but it's a workaround at best. See above. This
problem comes in a variety of places and is by no means limited to menus
(although it shows there in quite unacceptable ways).

> I'd look into where all the property scanning is going on, 
> and see if I couldn't reduce it.

Wouldn't even bother with it at this point. If you can't say where it's
coming from you can't really do anything about the critical places.

Cheers,
  - Andreas




More information about the Squeak-dev mailing list