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

Dan Ingalls Dan at SqueakLand.org
Fri Aug 2 01:05:08 UTC 2002


Andreas -

>Just a little note on the above: None of the #startSteppingsubmorphsOf:
>is necessary. I got all of this fixed (since it was called all over the
>unlikeliest of places and still didn't work) in the #intoWorld: protocol
>which gets called whenever morphs show up in a world and not just by
>random chance (note that intoWorld: doesn't even show up, which means
>that startSteppingOf: is called repeatededly and for no reason
>whatsoever, hah!). E.g., startSteppingSubmorphsOf: is simply OBSOLETE
>and can be removed without any worries whatsoever. So the first thing to
>do is to make that method a no-op (which will bring down the above to
>exactly zero percent of the overall time).

Well, this *sounds* good, but when I look at the default method for intoWorld:,  I see it just calls wantsSteps, so why won't we just see the same tallies under intoWorld: instead of startSteppingSubmorphsOf:.  Am I missing something?

> > (*) 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.
>
>... if you still want to do this all you need is to call the initial
>step from intoWorld: which is both, simple and efficient (since you
>won't even bother to register a morph with the stepping machinery if it
>returns false). But actually I seriously doubt that you really need it-
>it gets called if and ONLY if the morph shows up in the world and I've
>never seen it in any tallies I have run.

Well, I won't fix it if it ain't broke, except for the continued ugly sensitivity to adding step to Object or ProtoObject -- there should at least be a placeholder there to manifest the invisible protocol.

	- Dan



More information about the Squeak-dev mailing list