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
|