`just slow it`....

Stefan Matthias Aust sma at 3plus4.de
Sat Feb 10 10:35:20 UTC 2001


At 21:27 08.02.01 -0800, you wrote:
>Thanks for the information!

You're welcome.

 >> [OS color depth should be Squeak color depth]

> > Good point.  Unfortunately, the Unix VM has no 24 bit mode
> > which would be my OS mode.  This could explain some part of the delay.
>
>It most certainly does. I am not sure (Unix people might be able to answer 
>that question) but I also think that using the X shared memory extensions 
>makes a huge difference. Is there any way of finding out if it's used or not?!

Well, I meant "Squeak" not "Unix VM".  My X has a color depth of 24 bits 
which isn't matched by Squeak. This means the VM has to translate Squeak's 
16 bit or 32 bit into 24 bits.  I use the "-xshm" extension so if shared 
memory is available, I should get it.  However, I never really noticed any 
significant difference which might be because of the Sunray client stuff.

>Quite a difference I'd say. Must be Bowie ;-)

Okay, I rechecked while playing "Rosenstolz" and it's still the same 
performance... :-)

Ahem, but here's more serious observation: I recompiled the Solaris VM 
using Sun's CC and got a 13% performance improvement.  I used CC=cc, 
CFLAGS=-xO5 vs. CC=gcc, CFLAGS=-O3.  Then I also checked the generated 
SPARC assembler code (weird stuff) for interp.c and noticed also SUN's 
compiler generates the superfluous "if byte >= 255" test.  So it could be 
even faster if you'd help it with some assembler, similar as the gnuify 
script rewrites the switch to allow gcc better optimization.

>Most of these could be display related. Here is an interesting benchmark: 
>[...]

I'll try it out Monday.  Thanks.

 From the windows benchmark, it seems that only ~8% are used to force the 
display to the screen. 6% of processing time are used (wasted) to round the 
corners.  18% are spent for layouting the browser.  It takes 27% to build 
the system categories list and of that, 13% to do no highlight.


> >[message tally]
>This looks like you might try to disable #smartUpdating of browsers (it's 
>a preference). But everything else looks quite reasonable to me.

It's nice that you and Bob and others find places where you can save some 
time by disabling features.  However, I want all the features and still a 
fast system.  For the user's point of view, it's a poor choice just to 
disable features to get a reasonable performance.

I think, the problem is not smart updating but how it's 
implemented.  Browsers should notify each other (as for example done in 
Dolphin Smalltalk) and not poll for changes. Iehk.

bye
--
Stefan Matthias Aust \\ Truth Until Paradox





More information about the Squeak-dev mailing list