Morphic slowness (was Re: Does *anyone* use MVC?)
Tim Rowledge
tim at sumeru.stanford.edu
Sat Aug 3 00:54:34 UTC 2002
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
|