Sam | 3 May 05:47 2002
Picon

excessive time for initial paint

I've investigated a problem that Ivan Eisen is seeing/reporting 
regarding instances of very long times for the initial paint of 
large/long documents. The source of the problem is such. In 
layout\html\base\src\nsPresShell.cpp implements mPaintSuppressionTimer, 
with intent to supress initial painting of large docuements for a while, 
default 1200 ms. The timer itself is working okay, but the handling of 
the timer timeout is a bit broken. In 
PresShell::UnsuppressAndInvalidate() is a path leading to cv->Show();
The Show() leads to a reflow which should perform the paint. However, it 
doesn't because mPaintingSuppressed = PR_FALSE; hasn't been set yet. The 
mPaintingSuppressed = PR_FALSE needs to be set before the call to 
Show(). When changed such, then the initial paint delay is more closely 
honored.
Sam

Sam Emrick | 3 May 05:56 2002
Picon

excessive time for initial paint delay

I've investigated a problem that Ivan Eisen is seeing/reporting regarding
instances of very long times for the initial paint of large/long documents.
On Windows NT, the problem further seen by lockup of gui responsiveness for
long periods in document load.

The source of the problem is such. In layout\html\base\src\nsPresShell.cpp
implements mPaintSuppressionTimer, with intent to supress initial painting
of large docuements for a while, default 1200 ms. The timer itself is
working okay, but the handling of the timer timeout is a bit broken. In
PresShell::UnsuppressAndInvalidate() is a path leading to cv->Show(); The
Show() leads to a reflow which should perform the paint. However, it
doesn't because mPaintingSuppressed = PR_FALSE; hasn't been set yet. The
mPaintingSuppressed = PR_FALSE needs to be set before the call to Show().
When changed such, then the initial paint delay time is mush more closely
honored.
Sam

Suresh Duddi | 3 May 15:31 2002
Picon

Category report from spacetrace

We have implemented categorization in spacetrace. This is similar to the 
stacktrace based rule matching that brendan/waterson did but does it 
more in the context of the spacetrace tool. With this spacetrace will 
let you focus on a particular category.

I took a first stab at the rules file. Owners please help refine it.
http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/rules.txt

The categorization is not exact but gives more than a ballpark - 
optimized for speed. I have attached the report it generated (formatted 
to text).

NOTE: I will post more accurate categorized data betn testgtkembed and 
mozilla later. This is data I collected about a week ago at two 
different points. So dont compare them too much.

TestGtkEmbed:
All                  [ 5,144,384 size, 100.0%,  48,422 allocations ]
--------------------------------------------------------------------
html                 [ 1,004,088 size,  19.5%,   9,423 allocations ]
images               [   847,240 size,  16.5%,     481 allocations ]
xpcom                [   675,104 size,  13.1%,   7,852 allocations ]
necko                [   345,088 size,   6.7%,   1,512 allocations ]
font                 [   329,160 size,   6.4%,   5,585 allocations ]
css                  [   313,704 size,   6.1%,   5,289 allocations ]
uncategorized        [   289,688 size,   5.6%,   3,361 allocations ]
js                   [   212,800 size,   4.1%,   3,270 allocations ]
global-history       [   172,920 size,   3.4%,      65 allocations ]
X                    [   151,648 size,   2.9%,   2,414 allocations ]
jar                  [   134,080 size,   2.6%,     122 allocations ]
(Continue reading)

Daniel Bratell | 3 May 21:56 2002
Picon
Picon
Picon

Re: excessive time for initial paint delay

Sam Emrick wrote:
> I've investigated a problem that Ivan Eisen is seeing/reporting regarding
> instances of very long times for the initial paint of large/long documents.
> On Windows NT, the problem further seen by lockup of gui responsiveness for
> long periods in document load.

Interesting! Do you have the bug number? If this is an easy and safe 
fix, it's probably wanted for 1.0.

/Daniel

adrian Merrill | 3 May 22:22 2002
Picon

Perf: comet/xulwinopen test regression

Anyone else notice the regression in xulwinopen at 11:00 pm?  Times on 
comet went
from ~460 to ~470.  This is a slow down of around 3%, however we got an 
improvement of
around 3% in startup at around the same time.

I think that this is due to the checkings for bug 112064
http://bugzilla.mozilla.org/show_bug.cgi?id=112064

I was wondering about the trade off here, since new windows are created 
hundreds of times
more often than the application is started.

Sam | 3 May 23:54 2002
Picon

Re: excessive time for initial paint delay

Daniel Bratell wrote:

> Sam Emrick wrote:
> 
>> I've investigated a problem that Ivan Eisen is seeing/reporting regarding
>> instances of very long times for the initial paint of large/long 
>> documents.
>> On Windows NT, the problem further seen by lockup of gui 
>> responsiveness for
>> long periods in document load.
> 
> 
> Interesting! Do you have the bug number? If this is an easy and safe 
> fix, it's probably wanted for 1.0.
> 
> /Daniel
> 

I really hate to write new bugs. With bugzilla query 'slow' returning 
217 bugs, I'm sure one or more of the 217 must apply. This is response 
to "Large Text documents do not display anyting...." message by Ivan 
above (I don't know how ref-link a newsgroup message into newsgroup 
message). It's probably most problematic on fast networks, our 
client/server network is 100Mbps ethernet. Code level is RC1. AFAIK its 
a one line fix.

Daniel Bratell | 4 May 09:01 2002
Picon
Picon
Picon

Re: excessive time for initial paint delay

>> Interesting! Do you have the bug number? If this is an easy and safe 
>> fix, it's probably wanted for 1.0.
>>
> 
> I really hate to write new bugs. With bugzilla query 'slow' returning 
> 217 bugs, I'm sure one or more of the 217 must apply. This is response 
> to "Large Text documents do not display anyting...." message by Ivan 
> above (I don't know how ref-link a newsgroup message into newsgroup 
> message). It's probably most problematic on fast networks, our 
> client/server network is 100Mbps ethernet. Code level is RC1. AFAIK its 
> a one line fix.

But unless its written in a bug it can't be tested, reviewed and checked 
in. I don't care if it's a new or an old bug. You're probably right that 
there already exist a bug report for it, but I don't know which so I can 
not track it and/or push for it.

/Daniel

Boris Zbarsky | 4 May 16:41 2002
Picon

Re: excessive time for initial paint delay

Daniel Bratell wrote:
> Sam Emrick wrote:
>> I've investigated a problem that Ivan Eisen is seeing/reporting regarding
>> instances of very long times for the initial paint of large/long 
>> documents.
>> On Windows NT, the problem further seen by lockup of gui 
>> responsiveness for
>> long periods in document load.
> 
> 
> Interesting! Do you have the bug number? If this is an easy and safe 
> fix, it's probably wanted for 1.0.

At a guess, this could be bug 110106 and/or bug 129640....

Sam | 5 May 06:34 2002
Picon

Re: excessive time for initial paint delay

Boris Zbarsky wrote:

> 
> At a guess, this could be bug 110106 and/or bug 129640....
> 

Thanks Boris, 110106 is applicapble. I put a comments there.

Chris McAfee | 5 May 07:36 2002

Re: Perf: comet/xulwinopen test regression

adrian Merrill wrote:
> Anyone else notice the regression in xulwinopen at 11:00 pm?  Times on 
> comet went
> from ~460 to ~470.  This is a slow down of around 3%, however we got an 
> improvement of
> around 3% in startup at around the same time.
> 
> I think that this is due to the checkings for bug 112064
> http://bugzilla.mozilla.org/show_bug.cgi?id=112064
> 
> I was wondering about the trade off here, since new windows are created 
> hundreds of times
> more often than the application is started.
> 
> 

Cathleen was looking at this on Friday, not sure if there's
a bug yet.

-Chris


Gmane