377419 - At <www.pro-at.com>, abnormal processor usage, related to Flash + JavaScript

Status: RESOLVED WORKSFORME

(Core :: General, defect, P3)

Description

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.3pre) Gecko/2007031003 BonEcho/2.0.0.3pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414] (release) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.12pre) Gecko/20070322 SeaMonkey/1.0.8] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/20070405 SeaMonkey/1.1.1] (nightly) (W2Ksp4)
[Microsoft Internet Explorer, version 6.0.2800.1106 (128b, SP1)] (release++) (W2Ksp4)

No bug.


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031004 Minefield/3.0a3pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070412 SeaMonkey/1.5a] (nightly) (W2Ksp4)

0. Start (Windows) TaskMgr. (or any equivalent tool)
1. Load URL.
2. Wait for +/- 5 seconds.
3. See how FF/SM process memory usage starts to increase steadily.
3r. I noticed slowdowns and got up to 750 MB before SM hang and had to be killed.

Comment 1

[Brian Polidoro]

I see the site spikes the CPU but I don't see any memory growth.  

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070413 Minefield/3.0a4pre ID:2007041304

Comment 2

[Bengt-Erik Soderstrom]

I do not see any significant increase in memory consumption (used about 480 MB), but I do see that this site takes about 99-100% CPU. 
(My own trunk build:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre Gecko/20070413 Minefield/3.0a4pre, VC8 Express).

But instead trying Firefox 2.0.0.3 -official build, the CPU use is only some 3% displaying this URL
Using Seamonkey (also today's trunk build) in Linux FC6, the CPU use is only some 2% with this URL.

I'd say that there is indeed something wrong with the Windows trunk version of Firefox

Comment 3

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/20070413 SeaMonkey/1.1.1] (nightly) (W2Ksp4)

No bug. (simply confirming with latest SM 1.1.1+ nightly)


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070413 SeaMonkey/1.5a] (nightly) (W2Ksp4)

1)
Right, I had not paid enough attention:
I get a 10-20% (Core 2 Duo E6300) cpu usage too !
I noticed that my cpu usage drops back to "2%" while another (maximed) window (SM or other app.) "hides" the Browser window.

2)
I tested again, and it seems the delay before the memory usage growth happens is more like 30 seconds ... (how long did you waited, to be sure ? Did you (try and) restart FF/SM before testing ?)
After it has started, the memory increases as long as the page is loaded, whether the window is shown/"hidden"/minimized.
NB: With (SysInternals) Process Explorer, I see the "Private Bytes" increasing.

*)
Then, there could be 2 (related !?) issues.

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #3)
> I noticed that my cpu usage drops back to "2%" while another (maximed) window
> (SM or other app.) "hides" the Browser window.

Or to select another tab has the same effect.

Comment 5

[Brian Polidoro]

I waited a few minutes.  On another machine I have a little older build and still no memory problem.  I tried my regular profile and a clean one. 

I would venture a guess that the 30 second wait for the memory leak could be when the flash ad switches. Which version of flash are you using?  

Also the CPU spike stopped when I disabled javascript in the browser.  But blocking everything except images with adblock plus didn't stop the cpu spike so it must be a script in the page itself that's the cause.  

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070409 Minefield/3.0a4pre ID:2007040904
Flash 9.0 r28

Comment 6

[Serge Gautherie (:sgautherie)]

CPU)
I confirm that "javascript.enabled = false" leaves my cpu at 0%.
So does enabling JS, but removing Flash plugin.


Memory)
But disabling JS and keeping the Flash plugin still shows the memory leak (only).

I had |Shockwave Flash 9.0 r28| too.
(My (zipped) SeaMonkey find it in Netscape Communicator (v4.80) <Plugins> directory.)
Then I installed |Shockwave Flash 9.0 r45| (in <Windows> directory): same issue.

There is only one Flash ad:
<http://www.pro-at.com/images/partenaires/zonebourse/zonebourse_88x31.swf>
(It's on the left, under "Conseils actions".)


(Same 2 issues with a new profile.)


Regression timeframes)

memory growth only (There's no Windows builds on 10th and 11th: only linux or mac)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060509 SeaMonkey/1.5a] (2006-05-09-10-trunk) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060512 SeaMonkey/1.5a] (2006-05-12-10-trunk) (W2Ksp4)
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-09+10&maxdate=2006-05-12+11&cvsroot=%2Fcvsroot>
My guesses: bug 312238 and bug 337407 (igor), bug 326273 (darin) [May not be involved, but mentionning as major change].

(m.g. and) cpu usage
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061126 SeaMonkey/1.5a] (2006-11-26-09-trunk) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061127 SeaMonkey/1.5a] (2006-11-27-09-trunk) (W2Ksp4)
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-26+09&maxdate=2006-11-27+10&cvsroot=%2Fcvsroot>
My guesses: bug 356851 (peterv), bug 361707 (roc).

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> My guesses: bug 312238 and bug 337407 (igor), bug 326273 (darin) [May not be
> involved, but mentionning as major change].

After noticing the same memory issue with a SWF file at <http://www.zonebourse.com/>,
I thought to search BMO again, now that you pointed me to (JS and) Flash,
and immediately found
[Bug 342810 – threadmanager checkin 2006-05-10 causes increased memory usage by ~10MB per minute with shockwave flash (memory leak?)]
;-<

Then, morphing this/my bug:
was Memory only -> is Memory and Cpu -> will be Cpu only :->

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> <http://www.pro-at.com/images/partenaires/zonebourse/zonebourse_88x31.swf>

a)
I tried to run the SWF directly in the (SeaMonkey) browser window:
v1.0.8+, v1.1.1+ and v1.5a- behaves the same way:
my cpu goes back and forth between 0+ and 40%.
(De)Activating JavaScript does not seem to make an noticable difference.

b)
I tested again the whole HTML page without->with JavaScript enabled:
SMv1.0.8+  0+-02  01-13
SMv1.1.1+  0+-0+  0+-02
SMv1.5a-   0+-07  08-15
FFv3.0a-   0+-02  08-17

I won't bother with v1.8.0 branch, which is very near its end of life.
I will assume that the small (in this simple test) increase with the v1.8.1 is due to JS code actually being executed ;->
Which leaves this bug, quite visible, with the v1.9 branch !

Comment 9

[Boris Zbarsky [:bzbarsky]]

So when did this regress?  What's the one-day range (including the hours on the builds)?

Comment 10

[Serge Gautherie (:sgautherie)]

Boris,

(In reply to comment #6)
> Regression timeframes)
> (m.g. and) cpu usage
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061126
> SeaMonkey/1.5a] (2006-11-26-09-trunk) (W2Ksp4)
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061127
> SeaMonkey/1.5a] (2006-11-27-09-trunk) (W2Ksp4)
> <http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-26+09&maxdate=2006-11-27+10&cvsroot=%2Fcvsroot>
> My guesses: bug 356851 (peterv), bug 361707 (roc).

I do hope YOU can help from there.!.

Comment 11

[Boris Zbarsky [:bzbarsky]]

roc's change should not have affected this.

Then again, neither should have peterv's.

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> <http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-26+09&maxdate=2006-11-27+10&cvsroot=%2Fcvsroot>

The same, without a /toolkit patch:
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-26+09&maxdate=2006-11-27+10&cvsroot=%2Fcvsroot>

***

Unexpected: Firefox timeframe is 10 days later...

"No" cpu
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a1] (2006-12-06-06-trunk) (W2Ksp4)
"sometimes, half" cpu (!?) {I think I saw something like that for SeaMonkey too !?}
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120704 Minefield/3.0a1] (2006-12-07-04-trunk) (W2Ksp4)
always cpu
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1] (2006-12-08-04-trunk) (W2Ksp4)
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-12-07+04&maxdate=2006-12-08+05&cvsroot=%2Fcvsroot>
Nothing obvious to me: on its own, or related to SeaMonkey timeframe.

Otherwise, could it be that something changed on the compiling environment, like VC6->VC8, or things like that ??

Comment 13

[Robert Kaiser]

Ugh, the VC6->VC8 change might have been there, but I'm not sure, November is a long time ago to remember config changes. But then... don't we have a tool that tracks bug reports? Oh, yes, we do have one ;-)
And bug 356462 would even have comments from that timeframe - it's only comments though, it's been fixed before. Still, finding out when we really finally switched to VC8 builds is not entirely clear. Also the in-tree tinderbox configs have no history telling that, other then it must have been around October 2006, as they date back to 2006-10-11, so the new VC8 box was probably create back then.

Still, I'm pretty sure Firefox was turned to VC8 _before_ SeaMonkey, not 10 days later...

Comment 14

[Serge Gautherie (:sgautherie)]

Makes sense.

Then, how could we find out what is going wrong ?
Someone could recompile these old builds ?
Or use a debugger to try and see what is happening in current builds ?

Comment 15

[Serge Gautherie (:sgautherie)]

Attachment: ProAT page, very simplified

This is quite near to the point where moving/deleting anything makes the bug disappear.

With FF/SM trunk, cpu usage is 4-9% (the value was reduced when I removed some of the other content.) instead of 0-2%. [on my cpu]

Comment 16

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2] (release) (W2Ksp4)

No (memory nor cpu) bug.


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007060614 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

New SMv2 trunk had (both memory and cpu) bug.


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007060902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

(In reply to comment #7)

Memory leak: Much better after recent bug 342810 fix.
There might still be a much (s)lower mlk remaining, but it's harder to tell from TaskMgr only.
I'll wait for the cpu usage fix, before checking this again...

(In reply to comment #15)

Cpu activity, only when window is visible, is still there.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> I'll wait for the cpu usage fix

Which fix?

Comment 18

[Serge Gautherie (:sgautherie)]

No fix yet: I meant the one there will be someday, hopefully.

Comment 19

[Serge Gautherie (:sgautherie)]

Jim, just in case:
notice my attached testcase,
and the regression timeframe(s) from comment 6 and comment 12.

Comment 20

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007061602 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Confirming bug 342810 comment 140:
cpu usage bug still there after full bug 342810 patch.
(This could be expected as the regression timeframe is 6 months later.)

Comment 22

[Jim Mathies [:jimm]]

Related: bug 342043
site: http://wetter.rtl.de/deutschland/uebersicht.php?id=10708&id2=10708&ort=Saarbr%FCcken

Comment 23

[Serge Gautherie (:sgautherie)]

Trunk cpu usage bug still there:

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.8pre) Gecko/2007100303 BonEcho/2.0.0.8pre] (nightly) (W2Ksp4)

(0-4% on my computer.)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007100304 Minefield/3.0a9pre] (nightly) (W2Ksp4)

7-14% on my computer.

Comment 24

[Damon Sicore (:damons)]

OK.  This doesn't look good to me.  +'ing.  Setting this to P3 so we can look at it during the beta 3 dev phase.

Comment 25

[Jim Mathies [:jimm]]

Attachment: test html page v.1 (Bug 397303 actually)

New test case, based on the last only with some cleanup, flash removed, added iframes, and a longer scroll on the text. Note the more iframes you insert into the page, the worse the cpu drag gets. No iframes above the scrolling text ~0-2% cpu usage, 10 iframes, ~30-40% cpu usage. IE shows no increase regardless.

Seems to me this has to do with layout performance / rendering, rather than scripting and flash.

Comment 26

[Serge Gautherie (:sgautherie)]

(In reply to comment #25)
> Created an attachment (id=291763) [details]
> test html page v.1

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7] (release) (W2Ksp4)

No bug.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007120503 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

No bug at first glance;
but my cpu usage jumps from 0% to 27% if I Ctrl+Click in the scrolling div;
then drops back to 0% if I click elsewhere.

I confirm that the cpu usage depends on the number of div actually visible:
if I go to the bottom of the page, the bug is +/- unnoticeable,
if I stay at the top of the page, I get the maximum cpu load.

Comment 27

[Wayne Mery (:wsmwk)]

(In reply to comment #25)
> Created an attachment (id=291763) [details]
> test html page v.1

tested on vista, idle screen - no scrolling or clicking

~1% Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a5pre) Gecko/20070529 Minefield/3.0a5pre

13-20% Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a5pre) Gecko/20070530 Minefield/3.0a5pre

there's a ton of checkins in the range 2007-05-29 04:00 and 2007-05-30 04:00
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-29+04%3A00%3A00&maxdate=2007-05-30+04%3A00%3A00&cvsroot=%2Fcvsroot

Comment 28

[Wayne Mery (:wsmwk)]

(didn't intend to change assignment)

Comment 29

[Jim Mathies [:jimm]]

Attachment: callgraph

Finally got a profiler up and running on windows that can handle firefox. The culprit appears to be changes in this extremely large patch related to rendering - 

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/layout/base&command=DIFF_FRAMESET&file=nsCSSRendering.cpp&rev1=3.316&rev2=3.317&root=/cvsroot

Attached is a screengrab from AQtime, which shows the culprit functions and the amount of time we spend in them with this page loaded. Total runtime was 61 seconds.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Interesting.  Does setting "border-style: solid" on the iframe help with the performance on the testcase?  If it does, then part of the issue might be bug 397303.

That said, should we be invalidating rects including the border?  I guess we end up doing it because the scroller goes under the iframe?

Comment 31

[Jim Mathies [:jimm]]

Attachment: test solid border html page v.1 ("no" Bug 397303 actually)

> Interesting.  Does setting "border-style: solid" on the iframe help with the
> performance on the testcase?  If it does, then part of the issue might be bug
> 397303.

Somewhat. The first run using the shaded borders was a 4:23 minute run, of which (if I'm reading AQtime's summery report correctly) about 62 seconds was spent in the two libs I'm profiling (gkgfx.dll & thebes.dll). On a second run using solid borders (4:25 run time) we spent 39 seconds in those libs. The call graph was also quite different.  

> That said, should we be invalidating rects including the border? I guess we
> end up doing it because the scroller goes under the iframe?

I added a border around the scroller, it's not underneath. AFAICT, were rendering all the rects every time when we should probably be clipping that region out. I'll attach the second call graph here in a sec.

Comment 32

[Jim Mathies [:jimm]]

Attachment: solid border callgraph

Comment 33

[Boris Zbarsky [:bzbarsky]]

Jim, you're profiling the original page, not the first attachment on this bug, right?  I was looking at the attachment when I said the scroller goes under the iframe...

If that doesn't happen on the original page but we still repaint the iframe, we should figure out why.  Invalidating too much is always bad.

Comment 34

[Jim Mathies [:jimm]]

>Jim, you're profiling the original page, not the first attachment on this bug,
>right? 

I'm profiling the test html page (second attachement) and the one I just added.

Comment 35

[Jim Mathies [:jimm]]

Looks like this would be helped by the patch in bug 397303. But again, I don't understand why we would be rendering those iframe borders. (I'm assuming all of them are being rendered becuase, adding iframes causes cpu usage to grow.) So maybe the problem here is that our shaded frame rendering is a slow and we have some sort of invalidation problem which the test cases help to magnify.

Comment 36

[Jim Mathies [:jimm]]

Ok, here's something interesting. The iframes and scroller are encompassed in a hidden table. Eliminate that and processor usage drops to 0. So I'd guess were invalidating the entire table for some reason.

Comment 37

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008011103 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

(With first Pro-AT attachment, Trunk still uses 5-10%, whereas v1.1.7 uses 0+%.)

***

While I'm happy to see work going on,
let me remind us that we might not be looking at the same bug(s).

My initial cpu usage timeframes:

(In reply to comment #6)
> (m.g. and) cpu usage
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061126
> SeaMonkey/1.5a] (2006-11-26-09-trunk) (W2Ksp4)
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061127
> SeaMonkey/1.5a] (2006-11-27-09-trunk) (W2Ksp4)
> <http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-26+09&maxdate=2006-11-27+10&cvsroot=%2Fcvsroot>
> My guesses: bug 356851 (peterv), bug 361707 (roc).

(In reply to comment #12)
> The same, without a /toolkit patch:
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-26+09&maxdate=2006-11-27+10&cvsroot=%2Fcvsroot>
> 
> ***
> 
> Unexpected: Firefox timeframe is 10 days later...
> 
> "No" cpu
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606
> Minefield/3.0a1] (2006-12-06-06-trunk) (W2Ksp4)
> "sometimes, half" cpu (!?) {I think I saw something like that for SeaMonkey too
> !?}
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120704
> Minefield/3.0a1] (2006-12-07-04-trunk) (W2Ksp4)
> always cpu
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804
> Minefield/3.0a1] (2006-12-08-04-trunk) (W2Ksp4)
> <http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2006-12-07+04&maxdate=2006-12-08+05&cvsroot=%2Fcvsroot>
> Nothing obvious to me: on its own, or related to SeaMonkey timeframe.

While recent comments are based on

(In reply to comment #27)
> (In reply to comment #25)
> > Created an attachment (id=291763) [details] [details]
> > test html page v.1
> 
> tested on vista, idle screen - no scrolling or clicking
> 
> ~1% Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a5pre) Gecko/20070529
> Minefield/3.0a5pre
> 
> 13-20% Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a5pre)
> Gecko/20070530 Minefield/3.0a5pre
> 
> there's a ton of checkins in the range 2007-05-29 04:00 and 2007-05-30 04:00
> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-29+04%3A00%3A00&maxdate=2007-05-30+04%3A00%3A00&cvsroot=%2Fcvsroot

which is nearly 6 months later.

In other words, comment 25 testcase may not trigger the same bug(s) as comment 15 testcase does !?

Anyway, we'll see where we get after fixing one bug after another ;->

Comment 38

[Boris Zbarsky [:bzbarsky]]

OK, this is exciting.  We're ending up reflowing the table, which makes sense.  When nsTableFrame::Reflow is called, the reflow state has mVResize set to true.  This happens because nsHTMLReflowState::InitResizeFlags sets mVResize to true in standards mode for auto-height frames if the frame's subtree is dirty (which in this case it is).  Of course in quirks mode the mVResize on the canvas frame (which seems bogus to me, fwiw: the computed size is the viewport size, but the actual size contains all the overflow as well) would propagate down to here, so mVResize would be true no matter what.

In any case, we end up in nsTableFrame::Reflow with mVResize true, so call SetGeometryDirty().  Then the geometry is dirty, so we call ReflowTable() and set reflowedChildren to true.  Then we hit this code:

  // If we reflowed all the rows, then invalidate the largest possible area
  // that either the table occupied before this reflow or will occupy after.
  if (reflowedChildren) {
    nsRect damage(0, 0, PR_MAX(mRect.width, aDesiredSize.width),
                  PR_MAX(mRect.height, aDesiredSize.height));
    damage.UnionRect(damage, aDesiredSize.mOverflowArea);
    nsRect* oldOverflowArea = GetOverflowAreaProperty();
    if (oldOverflowArea) {
      damage.UnionRect(damage, *oldOverflowArea);
    }
    Invalidate(damage);
  }

That's what kills us.  This code is purporting to fix bug 91491.  I think we should try fixing that and then seeing whether there is any remaining problem whatsoever...

The first thing I would try to do is to remove this code and see whether bug 91491 is still there.  Maybe, just maybe, we fixed the actual issue along the line, allowing us to remove this brute-force hack?

Comment 39

[Serge Gautherie (:sgautherie)]

Figures:

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7] (release) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008011403 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008011501 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

*ProAT page, very simplified:
  2+% in a5,  5+% in b3-14, 2+% in b3-15, only 0-2% in v1.1.7.
  In a5 and b3-15, Ctrl+Click increases load from 2+% to 4+%.
  FWIW, this load appears as Windows kernel (red) in Task Manager graph.
*test html page v.1 (+ Ctrl+Click + PageTop):
 10+% in a5, 23+% in b3-14,  0% in b3-15.
*test solid border html page v.1 :
 0%.

My analysis:
*There was a 3rd regression between theses a5 and b3-14 nightlies,
 which was fixed by bug 397303 comment 17 checkin :-)
 Thanks Jim and Boris for looking into it.
*Theses same testcase and checkin showed/fixed a 2nd regression which was already in the a5 nightly.
*Yet, as I said before, all this was not related to the 1st regression,
 which is still there in b3-15 as it was in that a5.

Restoring previous component and summary which were changed on "2007-12-06 06:56:00 PST".

***

Boris, does your comment 38 apply to the current bug or to bug 397303 ?

Comment 40

[Serge Gautherie (:sgautherie)]

(In reply to comment #39)
> *ProAT page, very simplified:
>   2+% in a5,  5+% in b3-14, 2+% in b3-15, only 0-2% in v1.1.7.
>   In a5 and b3-15, Ctrl+Click increases load from 2+% to 4+%.
>   FWIW, this load appears as Windows kernel (red) in Task Manager graph.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008012704 Minefield/3.0b3pre] (nightly) (W2Ksp4)

Firefox still shows this same (1st) regression/load too.

Comment 41

[Boris Zbarsky [:bzbarsky]]

Comment 38 applies to this bug.  Perhaps it should get spun off into its own bug, however.  I'll do that.

Comment 42

[Boris Zbarsky [:bzbarsky]]

I should note that it's not likely that bug 397303 would have fixed two separate regressions.  That bug was just making painting slow; the regressions might have had to do with painting getting slower, or might have had to do with us invalidating too much.  If the latter, we need separate bugs on them and should fix those bugs for 1.9.  

Do we have 1-day regression ranges for those two regressions?

Comment 43

[Serge Gautherie (:sgautherie)]

(In reply to comment #42)
> Do we have 1-day regression ranges for those two regressions?

"3rd regression":
comment 27 and comment 29 seem to have the answer,
which fits with being later than the a5-070515 I tested.

"2nd regression":
No better timeframe than "before a5-070515" (yet),
as I didn't know it was there before it was fixed :->

Comment 44

[Boris Zbarsky [:bzbarsky]]

> "3rd regression":

Right.  That was the border rewrite.  That one I would expect to be affected by the inset/outset bug.

> "2nd regression":

A range would be good here.

Comment 45

[Boris Zbarsky [:bzbarsky]]

I filed bug 414298 on the table invalidation issue.

Comment 46

[Serge Gautherie (:sgautherie)]

(In reply to comment #44)
> > "2nd regression":
> 
> A range would be good here.

I gave it a try, then gave up:
it would seem (cpu usage) regressions came by and went away all along the 1.9 cycle :-<

 0+% [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070101 SeaMonkey/1.5a] (nightly) (W2Ksp4)
13+% [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070208 SeaMonkey/1.5a] (nightly) (W2Ksp4)
 3+% [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070315 SeaMonkey/1.5a] (nightly) (W2Ksp4)
 0+% [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070407 SeaMonkey/1.5a] (nightly) (W2Ksp4)
 0+% [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070426 SeaMonkey/1.5a] (nightly) (W2Ksp4)
10+% [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)

The common point to this "group" of regressions is the "border issue",
as I see 0+% until I Ctrl+Click and the borders are shown.

Regarding your comment 42, which I agree with,
I think the best/only course of action would be to adapt this testcase and include it in the testsuite for bug 397303, if cpu usage can be (automatically) monitored (or anything else that would detect the underlying regression)...

***

Back to the current bug :->

Comment 47

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

What testcase should I be using here?  Ideally I need something that's very slow and that'll result in a number, but even something that's just generally measurably slow to render would be useful.

Comment 48

[Martijn Wargers (dead)]

Well, bug 379834 might be related. I could probably change the borders of that testcase to use inset/outset and I suspect it would still be relatively slow.

Comment 49

[Serge Gautherie (:sgautherie)]

(In reply to comment #47)
> What testcase should I be using here?

For bug 397303 ? Then:
based on my tests,
you should modify "test html page v.1 (Bug 397303 actually)" so that the borders are shown (as using Ctrl+Click)...

(For the current bug ? The "Pro-AT" testcase "as it is".)

Comment 50

[Jim Mathies [:jimm]]

Ok, just to clarify, we're all the way back to the original test case 

>Created an attachment (id=262442) [details]
>ProAT page, very simplified

We still have a CPU utilization problem independent of the drawing stuff we found on the tables.

Comment 51

[Serge Gautherie (:sgautherie)]

(In reply to comment #50)
> Ok, just to clarify, we're all the way back to the original test case 

(Right, that's what I meant.)

> We still have a CPU utilization problem independent of the drawing stuff we
> found on the tables.

From Boris's comments, I understood this is independent of bug 397303, but is dependent on bug 414298. Did I get it right ?

Comment 52

[Jim Mathies [:jimm]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

CPU - %2 -> %5 (1.5GHz C2D laptop)

HEAD:

CPU - %4 -> %8 (debug build)

I don't see the problem here. Flash loops on WM_USER messages which are nsRunnables now -

https://bugzilla.mozilla.org/attachment.cgi?id=217591&action=diff#mozilla/modules/plugin/base/src/nsPluginNativeWindowWin.cpp_sec4

Is the increase between Fx2 and Fx3 "unexpected"? 

Comment 53

[Jim Mathies [:jimm]]

Those results were on the first test case (ProAT page, very simplified) with the hidden table removed. 

Comment 54

[Serge Gautherie (:sgautherie)]

Pro-AT testcase:

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008020602 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

2-5%

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008020702 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

0-2%
That may (or not) still be a little more than 0-1% with SM v1.1.7;
but bug 414298 does improve the situation a lot:
see Boris comment 38 and comment 45.

Now, let's see what happens with the regressions from that bug :-|

Comment 55

[Mike Beltzner [:beltzner, not reading bugmail]]

Moving bugs that aren't beta 4 blockers to target final release.

Comment 56

[Mike Beltzner [:beltzner, not reading bugmail]]

Latter comments imply that this is fixed / less of an issue?