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

Andreas Raab Andreas.Raab at gmx.de
Sat Aug 3 01:46:19 UTC 2002


Tim,

It's unlikely that this would help too much. 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. Secondly,
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. 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
workload.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Tim Rowledge
> Sent: Saturday, August 03, 2002 2:55 AM
> To: squeak-dev at lists.squeakfoundation.org
> Cc: Tim Rowledge
> Subject: Re: Morphic slowness (was Re: Does *anyone* use MVC?)
> 
> 
> Here's  possibly off the wall suggestion to tackle apparent 
> slowness in 
> some of the important areas of morphic applications.  It is 
> based on a 
> good deal of supposition that may be incorrect, inappropriate 
> and just 
> plain wrong. Caveat hackor.
> 
> My suspicion is that a good portion of time is being spent in 
> handling the 
> flexibility provided; all morphs can contain morphs, have 
> extensions, make 
> tea, butter toast etc. Well, guess what - probably 90%+ of the time a 
> lotof important morphs don't need any of that. So, my 
> suggestion is that 
> we consider making a subtree of classes relating to morphs that don't 
> implement anything to all this cleverness. For example, a 
> text view is 
> very rarely going to need to embed other morphs. If, as I am 
> supposing, 
> there is any time/space cost that can be saved for the normal 
> case, lets 
> have DumbTextMorph that is  explicitly a leaf node morph, 
> that simply does 
> the text handling  - like the MVC equivalent. If we want to 
> get clever, 
> make it possible to morph it into a 
> FullyCleverWhizzoTextMorph at need, 
> transparently. Use a bridge pattern if you like. Similarly I 
> suspect that 
> the normal case for menus, buttons, list what have you is 
> very plain usage.
>   Total flexibility is wonderful for prototyping and exciting 
> experiments 
> but often not so good for more settled usage.
> 
> Rather than simply profiling the existing code and improving 
> it, this is a 
> small plea to consider changing the algorithm to see if that 
> can make a 
> revolution rather than an evolution. Like all such 
> suggestions it may be 
> totally wrong headed. Feel free to laugh.
> tim
> 
> tim at sumeru.stanford.edu
> 
> 




More information about the Squeak-dev mailing list