Morphic slowness (was Re: Does *anyone* use MVC?)
tim at sumeru.stanford.edu
Sat Aug 3 02:50:55 UTC 2002
On Friday, August 2, 2002, at 06:46 PM, Andreas Raab wrote:
> It's unlikely that this would help too much.
It's entirely posible you're right.
> For one thing, there are a
> few issues which are deeply buried within the morphic kernel (see my
> recent note on the problem of doing layouts when invalidating morphs).
> Fixing these problems requires *deep* changes to the morphic kernel (so
> deep that I could never convince myself to do it and rather upgraded my
> machine) or to write a complete (and incompatible) widget set.
The deep morphic stuff is something I'm not even going to try to comment
upon; way outside my scope right now. However, not all situations can be
remedied by resorting to Moore's law, for example I can't get a faster
Acorn :-(, iPaqs are stuck as they are etc. So I hope there are things we
can get around to doing. Besides, morphic has been around for quite a
while and has accumulated a lot of cruft and it is probably time to at
least imagine possible benefits of replacing it with a cleaner rewrite.
Burn the class tree!
> once you start going down that path you will start using these amputated
> morphs until somebody comes who wants to use a whizz-bang feature and
> will revert it to the fully-fledged version and at that point you're
> back to square one.
Well exactly. Certainly one could argue that that results in no net gain
and a lot of work wasted but I posit that a moderately well worked out
DumpTextMorph would in fact be smart enough for a very large range of
typical usage. Thus one can make a counterclaim that for a lot of the time
there would in fact be a benefit.
> Thirdly, a number of problems (like recreating
> menus; invalidation policy deficiencies) cannot be solved by any of
> these techniques anyways and what is needed here is a fresh look to
> understand under which circumstances exactly we can avoid any additional
Oh absolutely. I was careful to refer to 'morphic applications' for
precisely this reason. It's very likely that a lot of time can be saved by
appropriate caching in places that are nothing much to do with the actual
morphic code. Indeed there are places where that might improve behaviour
and not just performance. One potential case I can think of is menu
opening where 'old' Smalltalk used to keep the menu around in text panes
and this meant that the menu popped up with the last chosen option already
to go again. I found this very pleasing if I remember correctly. A bit
more thought could make it pre-select paste after a copy/cut for example -
perhaps a good thing, perhaps not.
tim at sumeru.stanford.edu
"Oh Bother", said Pooh as the WorldMenu refreshed too much screen yet again
More information about the Squeak-dev