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