>On Thu, 1 Aug 2002 15:44:37 -0700 Ned Konz <ned at bike-nomad.com> wrote:
>>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!).

First of all, about this thread, it's great fun!  Every once in a while we get serious about performance and discover truly ghastly cruft growing in Squeak

	not because Squeak is so slow,
	but because it is so fast that
	it hasn't mattered.

I remember a year or two ago, responding to a similar complaint about world halos being sluggish, and I discovered that the entire world was being repainted to add or remove the halo!

Bob Arning  <arning at charm.net> observed...

> >In 3.2, I did this:
>>
>>MessageTally spyOn: [ World putUpWorldMenu: ActiveEvent ]
>
>For a comparison, here are numbers from a 700-MHz iMac (note that this opens 100 world menus), but first, some observations:
>====
>    |    |  |17.0% {696ms} MenuItemMorph(Morph)>>setBalloonText:
>    |    |  |  17.0% {696ms} MenuItemMorph(Morph)>>setBalloonText:maxLineLength:
>    |    |  |    17.0% {696ms} String>>withNoLineLongerThan:
>you could defer breaking the balloon text up until you really needed to display it since that is the exception rather than the rule.

Definitely!  I thought we did.

>====
>    |    7.7% {315ms} PasteUpMorph>>startSteppingSubmorphsOf:
>    |      7.7% {315ms} MenuItemMorph(Morph)>>wantsSteps
>    |        7.7% {315ms} StringMorph class(Behavior)>>includesSelector:
>    |          7.7% {315ms} MethodDictionary>>includesKey:
>this seems a bit much.

The whole wantsSteps mechanism is a crock IMO (at least as it is implemented right now).  This performance bug is only a mild problem.  It is a time-bomb waiting for any innocent newbie to add #step to object.  I have to admit fault here, as I've worked on it without fixing it several times in the past.

Regarding the performance, Morph>>wantsSteps could probably be made 5 times faster, but I claim that any reasonable replacement of the whole approach (*) would not even show up in the tallies!  If no one else jumps in first (it would be fun to do), then I'll tackle it.

I tremble to think how often this mechanism gets invoked all over morphic right now.

	- Dan

(*) The obvious solution I propose here is to eschew gratuitous intelligence, and declare that wantsSteps (like handlesMouseDown:, etc) should be a simple ^true (or simple local (non-hierarchy-traversing) logic), added in the hierarchy wherever step is added, and defaulted to ^false in Morph.  The extension to SystemWindow models can be equally simple.