There is not only a speed difference between 2.8 and 3.8; there is a 
notable difference between 3.6 and 3.7. With a profiler on it, one makes 
some observations (remember we are here in the basement of Morphic and 
the code gets run a lot):
- a. recently some "aColl size = o" were replaced by "aColl isEmpty" : 
afaik the former is inlined and the latter is a message send. In some 
places this matters and I reverted them in my image.
- b. similarly "aColl at:1' replaced by " aColl first"
- c. The method pane in the browser was changed from a 
PluggableListMorph with StringMorphs to a PLM with a lazy list 
implementation. Splendid! However the advantage seems to be offset by 
the switch to the two-way scrollpane as the default which emphasizes the 
problem d.. The scrollers are calculated twice, once at initialization, 
once when the real morphs are known.
- d. the liberal use of "extent:" triggers a layout every time (not a 
new problem).

It is said on the subject of code: "make it run, make it run correctly, 
make it fast", not "make it pretty"; making the code more readable at 
the expense of speed is not progress. The point is that changes to low 
level code should always be profiled?

Can we discuss this on the technical merits. An argument that everybody 
owns or should own a 2.4 GHz super something-or-other and that memory is 
cheap, is not to the point. On a recent trip in a rather poor part of 
the world in a small school I found Squeak running on an older machine ( 
a linux box with Squeak on a distro), because "Squeak delivers so much", 
a reputation we want keep.

tim Rowledge wrote:
> 
> On 25-Aug-05, at 6:26 PM, Günther Schmidt wrote:
> 
>> Tim,
>>
>> so, if the *right* people are working on it, Morphic can be made to go 
>> wooooosh?
> 
> 
> Honestly, I don't know how much could be done; messing with morphic has 
> not been my thing. I do strongly suspect that someone that knows plenty 
> about morphic lower levels would be able to make a lot of cleanups. In 
> my experience cleanups can make for very good performance improvements, 
> so I'm hopeful. However I have to say that a lot of code in the image 
> has become so staggeringly baroque, convoluted and mangulated that I 
> have trouble imagining cleanups without massive work. Does anyone have 
> the experience, interest and time to do it?
> 
> tim