Morphic "performance" [sic]

Tim Rowledge tim at
Wed Jun 20 22:36:51 UTC 2001

"Noel J. Bergman" <noel at> is widely believed to have written:

> A 50% overall improvement in Morphic would be a start, and 30% lighter in
> space might turn into even more performance on cache-light processors.
Damn right - get that code out there Andreas!
> With respect to Morphic performance, Tim has said on a couple of occasions
> that, in his opinion, a 4x overall improvement in "normal case performance"
> could be achieved, but that "somebody has to have the time to tackle it."
> One area he mentioned was that Morphic uses floating point extensively, and
> that is a major problem for some processors.  He quoted a 10x drop in
> performance going from real to emulated floating point, in one experiment.
My thesis ( and one I'm quite aware could be proved completely wrong if
ever it were possible to find time to really test it) is that a lot of
the code in morphic is there to allow all the wonderfully clever things
and that it ought to be possible (aside from all the normal performance
improving stuff we know and love) to make sure that the 'ordinary'
morphs (simple lists, text views, buttons, windows etc) do everything as
simply as possible. My claim is something like :- "the tricky stuff is
rarely used so make sure that not having it allows it to cost nothing".
Or something like that. I think that a reasonable approach would be to
have some way to create basic morphs to do basic work and have them
morph into clever morphs if a clever facility is needed.
> And no, I wasn't trying to cajole Tim into doing the work.  I really did
> interpret his comments the other night as suggesting that he was "in the
> mood" to tackle Morphic's performance problems.
Very much in the mood, but completely out of money to allow the time to
try it. Gimme a job!


Tim Rowledge, tim at,
E Pluribus UNIX.

More information about the Squeak-dev mailing list