Smalltalk › Squeak › Squeak - Dev

3.9 browser speed

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Andreas.Raab

3.9 browser speed

Hi Guys -

I noticed that briefly yesterday but did some more investigation today
and it turns out that the tools in 3.9 have become *really* slow. And
it's not just because of the TTF caching. I turned off TTFs completely
and noticed that things were still slow and then I devised a little
benchmark:

win := Browser openBrowser topView.
win extent: 600@350.
br := win model.
br systemCategoryListIndex: 1.
World doOneCycle.
Transcript cr; show: [1 to: 10 do:[:i|
br classListIndex: i.
World doOneCycle.
]] timeToRun.

The interesting thing about this benchmark is that you can run it
multiple times to "increase the load" by having more browsers on the
screen. I only noticed this accidentally but it turns out to be the
relevant part.

In 3.8 the above results in a sequence of
Run 1: 598 msecs
Run 2: 630 msecs
Run 3: 683 msecs
Run 4: 689 msecs
So there is a little bit of slowdown when you add more browsers which is
what I would expect (due to rounded corners triggering some extra
overdraw, the additional structure etc).

In 3.9 however, we get the following:
Run 1: 883 msecs
Run 2: 1311 msecs
Run 3: 1632 msecs
Run 4: 2006 msecs
After four runs, we need 2.5 times as long as the first run. Something
is causing a tremendous overhead for any additional browser on the
screen. This matches my experience though originally I had attributed
that to the TTF problems but it seems the issue is way deeper than that.
Any ideas what was changed in 3.9 that could cause that slowdown?

Cheers,
- Andreas

Pavel Krivanek

Re: 3.9 browser speed

Hi Andreas,

the reason will be in the gradient background of windows. The
background is processed during every update now but the previous
versions were more optimized.
I have tried this test on Squeak 3.9 with Skylark theme
(http://www.comtalk.net/Squeak/87) and it was without this slowdown
and about two times faster (without TTF).

-- Pavel

On 10/21/06, Andreas Raab <[hidden email]> wrote:

> Hi Guys -
>
> I noticed that briefly yesterday but did some more investigation today
> and it turns out that the tools in 3.9 have become *really* slow. And
> it's not just because of the TTF caching. I turned off TTFs completely
> and noticed that things were still slow and then I devised a little
> benchmark:
>
> win := Browser openBrowser topView.
> win extent: 600@350.
> br := win model.
> br systemCategoryListIndex: 1.
> World doOneCycle.
> Transcript cr; show: [1 to: 10 do:[:i|
> br classListIndex: i.
> World doOneCycle.
> ]] timeToRun.
>
> The interesting thing about this benchmark is that you can run it
> multiple times to "increase the load" by having more browsers on the
> screen. I only noticed this accidentally but it turns out to be the
> relevant part.
>
> In 3.8 the above results in a sequence of
> Run 1: 598 msecs
> Run 2: 630 msecs
> Run 3: 683 msecs
> Run 4: 689 msecs
> So there is a little bit of slowdown when you add more browsers which is
> what I would expect (due to rounded corners triggering some extra
> overdraw, the additional structure etc).
>
> In 3.9 however, we get the following:
> Run 1: 883 msecs
> Run 2: 1311 msecs
> Run 3: 1632 msecs
> Run 4: 2006 msecs
> After four runs, we need 2.5 times as long as the first run. Something
> is causing a tremendous overhead for any additional browser on the
> screen. This matches my experience though originally I had attributed
> that to the TTF problems but it seems the issue is way deeper than that.
> Any ideas what was changed in 3.9 that could cause that slowdown?
>
> Cheers,
> - Andreas
>
>

Andreas.Raab

Re: 3.9 browser speed

Pavel Krivanek wrote:
> the reason will be in the gradient background of windows. The
> background is processed during every update now but the previous
> versions were more optimized.

Good theory, but I don't think this is the problem. When I turn off both
TTFs and gradients in 3.9 I still get something like here:

Run 1: 811 msecs
Run 2: 1191 msecs
Run 3: 1483 msecs
Run 4: 1867 msecs

It's a little better but not significantly (and it still feels way too
slow). BTW, if anyone wants to repeat the experiments, the changes that
I did for this test were:
* setting the window title font to a non-TTF (Accuny 14 in my case)
* change SystemWindow>>gradientWithColor: to return just the color
So I'm still at a loss what has changed to introduce that slowdown.

Hm ... let me try something. Oh, yes, now *that* would explain it. Turn
on #debugShowDamage in 3.9 and watch how it redraws the entire screen
almost every time you click anywhere in a browser. Ouch. No idea why
that is but it sure explains the effect.

Cheers,
- Andreas

Pavel Krivanek

Re: 3.9 browser speed

On 10/21/06, Andreas Raab <[hidden email]> wrote:

I was talking about experiments with the Skylark theme without TTF.
There's no slowdown there, results on my laptop are

444
435
459
456
465

Skylark theme uses old-time approach to window rendering...

> It's a little better but not significantly (and it still feels way too
> slow). BTW, if anyone wants to repeat the experiments, the changes that
> I did for this test were:
> * setting the window title font to a non-TTF (Accuny 14 in my case)
> * change SystemWindow>>gradientWithColor: to return just the color
> So I'm still at a loss what has changed to introduce that slowdown.
>
> Hm ... let me try something. Oh, yes, now *that* would explain it. Turn
> on #debugShowDamage in 3.9 and watch how it redraws the entire screen
> almost every time you click anywhere in a browser. Ouch. No idea why
> that is but it sure explains the effect.
>
> Cheers,
> - Andreas
>

-- Pavel

keith1y

Re: 3.9 browser speed

In reply to this post by Andreas.Raab

> In 3.9 however, we get the following:
> Run 1: 883 msecs
> Run 2: 1311 msecs
> Run 3: 1632 msecs
> Run 4: 2006 msecs
> After four runs, we need 2.5 times as long as the first run. Something is

Andreas,

that would be my 2 second delay. I do like to have a few windows open.
Now if your machine is 3x as powerful as mine which is quite likely then
that would be my problem

thanks for looking into it

best regards

Keith
Send instant messages to your online friends http://uk.messenger.yahoo.com

stephane ducasse

Re: 3.9 browser speed

In reply to this post by Andreas.Raab

I took some images and did not change anything, here are some of the
results I got.

7033
3839
5494
6628

7000
5769
7698
9422
10554

seems that in between we got something...

6720

3767
5295
4924
5900
5788
5936
5264
here it seems that when the widgets are really overlapping the
behavior is different.

6696
5197
5597
7928
6833
8845

6678
4192
2741
2691
4326
4406

stephane ducasse

Re: 3.9 browser speed

Not the solution but I noticed that in RC3 there is pretty often and
regularly a complete display redraw just when selecting a different
class.

karl-8

BrowserCommentTextMorph Re: 3.9 browser speed

In reply to this post by Andreas.Raab

Andreas Raab skrev:

> Pavel Krivanek wrote:
>> the reason will be in the gradient background of windows. The
>> background is processed during every update now but the previous
>> versions were more optimized.
>
> Good theory, but I don't think this is the problem. When I turn off
> both TTFs and gradients in 3.9 I still get something like here:
>
> Run 1: 811 msecs
> Run 2: 1191 msecs
> Run 3: 1483 msecs
> Run 4: 1867 msecs
>
> It's a little better but not significantly (and it still feels way too
> slow). BTW, if anyone wants to repeat the experiments, the changes
> that I did for this test were:
> * setting the window title font to a non-TTF (Accuny 14 in my case)
> * change SystemWindow>>gradientWithColor: to return just the color
> So I'm still at a loss what has changed to introduce that slowdown.
>
> Hm ... let me try something. Oh, yes, now *that* would explain it.
> Turn on #debugShowDamage in 3.9 and watch how it redraws the entire
> screen almost every time you click anywhere in a browser. Ouch. No
> idea why that is but it sure explains the effect.

Commenting out some code in BrowserCommentTextMorph reduces the bogus
invalidation, so we have to debug the class BrowserCommentTextMorph to
see what make it behave so bad.
Karl

karl-8

Re: BrowserCommentTextMorph Re: 3.9 browser speed

karl skrev:

> Andreas Raab skrev:
>> Pavel Krivanek wrote:
>>> the reason will be in the gradient background of windows. The
>>> background is processed during every update now but the previous
>>> versions were more optimized.
>>
>> Good theory, but I don't think this is the problem. When I turn off
>> both TTFs and gradients in 3.9 I still get something like here:
>>
>> Run 1: 811 msecs
>> Run 2: 1191 msecs
>> Run 3: 1483 msecs
>> Run 4: 1867 msecs
>>
>> It's a little better but not significantly (and it still feels way
>> too slow). BTW, if anyone wants to repeat the experiments, the
>> changes that I did for this test were:
>> * setting the window title font to a non-TTF (Accuny 14 in my case)
>> * change SystemWindow>>gradientWithColor: to return just the color
>> So I'm still at a loss what has changed to introduce that slowdown.
>>
>> Hm ... let me try something. Oh, yes, now *that* would explain it.
>> Turn on #debugShowDamage in 3.9 and watch how it redraws the entire
>> screen almost every time you click anywhere in a browser. Ouch. No
>> idea why that is but it sure explains the effect.
> Commenting out some code in BrowserCommentTextMorph reduces the bogus
> invalidation, so we have to debug the class BrowserCommentTextMorph to
> see what make it behave so bad.
> Karl
>
>

I tracked the issue down to SystemWindows>>addPaneSplitters which
removes and adds pane splitters when the comment pane is added to the
bottom of the browser.
I'm not sure how to fix the issue, maybe hiding and showing the pane is
better than deleting and reinstalling it.
The root cause of the problem seem to be Morph>>privateAddMorph:atIndex:
which do a lot of invaliditation that cause a massive redraw when it's sent.
Karl

karl-8

[FIX]Re: BrowserCommentTextMorph Re: 3.9 browser speed

karl skrev:

> karl skrev:
>> Andreas Raab skrev:
>>> Pavel Krivanek wrote:
>>>> the reason will be in the gradient background of windows. The
>>>> background is processed during every update now but the previous
>>>> versions were more optimized.
>>>
>>> Good theory, but I don't think this is the problem. When I turn off
>>> both TTFs and gradients in 3.9 I still get something like here:
>>>
>>> Run 1: 811 msecs
>>> Run 2: 1191 msecs
>>> Run 3: 1483 msecs
>>> Run 4: 1867 msecs
>>>
>>> It's a little better but not significantly (and it still feels way
>>> too slow). BTW, if anyone wants to repeat the experiments, the
>>> changes that I did for this test were:
>>> * setting the window title font to a non-TTF (Accuny 14 in my case)
>>> * change SystemWindow>>gradientWithColor: to return just the color
>>> So I'm still at a loss what has changed to introduce that slowdown.
>>>
>>> Hm ... let me try something. Oh, yes, now *that* would explain it.
>>> Turn on #debugShowDamage in 3.9 and watch how it redraws the entire
>>> screen almost every time you click anywhere in a browser. Ouch. No
>>> idea why that is but it sure explains the effect.
>> Commenting out some code in BrowserCommentTextMorph reduces the
>> bogus invalidation, so we have to debug the class
>> BrowserCommentTextMorph to see what make it behave so bad.
>> Karl
>>
>>
> I tracked the issue down to SystemWindows>>addPaneSplitters which
> removes and adds pane splitters when the comment pane is added to the
> bottom of the browser.
> I'm not sure how to fix the issue, maybe hiding and showing the pane
> is better than deleting and reinstalling it.
> The root cause of the problem seem to be
> Morph>>privateAddMorph:atIndex: which do a lot of invaliditation that
> cause a massive redraw when it's sent.
> Karl
>
>

BorderedMorph wanted more specific position of the morphs added,

otherwise they would be added to the top left corner. Hope this cures it :-)

Karl

BorderedMorph.kfr.2.cs.gz (1K) Download Attachment