A lot of the 3.6-3.7 delta is due to primitives broken or disused during 
the i8n effort. These include basic font printing and text layout. (Try 
editing a big paragraph in a workspace, its not pleasant) These issues 
have been reported and hopefully will be improved for 3.9.

Thanks for pointing out some specific issues. Its a lot easier to work 
on those than the general 'it feels slow' comment. If people see any 
specific UI operations that seem unduly slow, feel free to post them 
here. They tend to make good small projects.

It would be nice if the compiler could inline stuff like array first 
that boils down to a single send, I have no idea how the compiler  works 
or if thats a sensible suggestion though. In some methods like the 
fallback character printing that are fixed-array access heavy, it makes 
around 25% difference between blah first second third etc and at:1 at:2 
at:3 etc.

As for other ideas for speeding things up, there is about a 10% 
improvement possible by caching gradients. I haven't quite got it 
packaged up yet. The deal is, all those small 16 pixel  icons with 
gradients each require a 512 element color array be generated, and most 
of them can be shared. i figured it would be easier to cache gradients 
rather than try to fix all the clients to share them manually. All those 
duplicated color maps also use a fair amount of space.

Eddie

frits swinkels wrote:

> 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
>
>
>