146831 - The CPU usage around 90% when load Netscape homepage

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Yuying Long]

Build: N7.0PR1 win32 build on WinXP-SimpChinese

With page http://home.netscape.com/ loaded, the CPU usage always very high
(about 90%).  It will be really slow when I try to do some other things, e.g.
Enable IME in Composer window to typing some other languages.

This problem appears after netscape.com page updated recently, I think it's
because now the page has a "marquee" scroll message simulation JavaScript right now.

I'm not quite sure if it's an envangelist issue or our application issue, I'm
filing bug for JavaScript for now, please change the component if needed.

Comment 1

[Yuying Long]

If I scroll down this page, then the CPU usage will go down about 30-40%.

FYI: a lots of SimpChinese web pages are using the scroll message, here are some
examples pages which are in top 5 SimpChinese pages from some date report:
http://www.sina.com.cn/
http://www.sohu.com/
http://www.stockstar.com/home.htm

Comment 2

[Yuying Long]

> If I scroll down this page, then the CPU usage will go down about 30-40%.
If I scroll down this page to hiding the JavaScript part, then the CPU usage
will go down about 30-40%.

Comment 3

[Rui Xu]

I don't have this problem on my SC XP with US 7.0PR1 and SC 7.0PR1 rc1. I always 
get 35% after starting http://home.netscape.com/ .

Comment 4

[Roy Yokoyama]

Rui Xu:  I came to see you to try the bug on your machine, but you aren't there. 
So I took a liberty of testing it without your presence.   

Indeed, your CPU doesnt' go up to near 90%; but it maintains at 35%.
And as soon as I scroll down the netscape page, CPU goes down to 2%.
IE, on the other hand, only bump CPU to max 8%.

I think Netscape browser _keeps_ too much CPU.

Comment 5

[Rui Xu]

Attachment: A screen shot of Task Manager

Roy and I just tested again on my SC XP pro, and got the screen shot for
comparison.

Comment 6

[kill this account]

I saw this and the simulated marquee appears to use so much CPU that
the Japanese IME was unusable. The IME has a "fade in" style animation effect.
When the simulated marquee is running the IME fade in takes so long that the
user is confused and thinks they did not engage the IME. Because they think 
they did not turn it on they end up turning it on/off/on/off ... further
compounding the CPU load and slowness.

Comment 7

[Phil Schwartau]

The performance issues here are in the browser code, not JS Engine.
Reassigning to DOM Level 0. I know there was recent talk about this
marquee. This may be a duplicate of 

bug 145152  Scrolling JS banner causes caret to "rapidly blink" in field

where the comment was made,
"This page also slows my system (G3 Powerbook) to a crawl."

Comment 8

[Bob Clary [:bc] (inactive)]

see also http://developer.netscape.com/evangelism/examples/stock-ticker/ which
is the original example the netscape.com ticker was derived from. The example
ticker does not load the cpu. 

I think there is an interaction with the markup on the page causes the cpu load.
I tried blocking mutation events and could not make a difference in the load.
Increasing the interval from 45 ms to 100 ms will drop the cpu load from 100% on
my PIII 700 to about 50%. 

Note that the netscape.com home page shows high cpu load even on Mozilla 2002 05
30 08 trunk.

Comment 9

[Doron Rosenberg (IBM)]

FYI, I'm writting a new ticker together with bclary that currently barelly uses
3% cpu, and am working with netcenter on this.

Comment 10

[Doron Rosenberg (IBM)]

http://blues.mcom.com/users/doron/publish/testcase.html

Here is a somewhat reduced testcase.  Removing the following inline css:
#navcontent
	{ position:absolute; text-align: right; top:240; width:145; }

reduces the cpu usage tremendously.

Comment 11

[Yuying Long]

Yes, I tried the above testcase, after I removed:
#navcontent... css style sheet, the CPU usage down from 90% to around 35%.	

Comment 12

[Yuying Long]

cc [e-mail] who might interested in this "marquee" simulation JavaScript.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: possible fix

This is a possible fix, but it needs a good bit of testing.  And I need to talk
to waterson about it...

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So it looks like what was going on is that there's an absolutely positioned
element within a table cell that is in the same row as the cell containing the
ticker.  It actually doesn't matter that their in the same row, because the real
absolute frame (not the placeholder) is parented to the block that is the child
of the canvas frame (the root element's frame).

I sat down to debug this with smontagu and darin.  I discovered from loading
doron's testcase in viewer and turning on visual debugging that the absolutely
positioned element in the testcase was flashing while repainting (I have
double-buffering turned off in my debug build, I think).  I put in printfs with
stack traces in nsFrame::Invalidate and found the stack trace that was leading
to these invalidates.

Basically what is happening is that when we do an incremental reflow targeted at
the ticker, since one of the ancestors of the ticker contains absolutely
positioned elements, we reflow all the absolutely positioned elements inside
that container.  (I think this means that we reflow all absolutely positioned
elements for any incremental reflow, which is even worse than the extra reflow
we do to find the overflow area after calling
mAbsoluteContainer.IncrementalReflow.)  So there are two problems:
 
 1) We're doing this reflow when we don't need to.
 2) This reflow leads to invalidates, even though nothing has changed.

I suspect (2) is somehow related to one of the major design flaws in layout --
the handling of min size / pref size within the same Reflow method and involving
the repositioning of frames, although BRS_COMPUTEMAXWIDTH, etc., might be able
to handle something like this.  It could be something simple, too, though.  I
think we were seeing invalidates from ReflowLine (invalidating the line box --
perhaps alexsavulov's change a few months ago?) and invalidates of the text
frame from some nsTextFrame code (which suggests to me that it involves
unconstrained/constrained jiggling due to the right-justification).

This patch addresses problem (1).  It looks like it's correct, but I'm still a
bit worried about any regressions it might cause (due to other problems that it
could be covering up).  I'd like to get the opinions of waterson, kin, and others.

Someone should still try this on Windows and make sure it solves the performance
problem there as well.

Comment 15

[Simon Montagu :smontagu]

On a Windows debug build without the patch CPU usage swings between 66% and 100%
depending on whether the ticker (or the absolutely positioned element) is hidden
or covered. With the patch CPU usage is fairly constant at 42%.

This is still a lot. Could we get more of a win by doing something along the
lines of bug 135146 comment 22?

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: same patch, but also change nsInlineFrame

This is the same as the previous one, but also changes some really obscure code
that is doing the same thing.

What smontagu mentions in comment 15 *might* be helpful -- we'd need to profile
with the patch to see what we're busy doing in that 42%.

Comment 17

[Simon Montagu :smontagu]

Attachment: Don't try this at home

As a quick and dirty proof of concept I copied code from bug 135146 to make
table cells act as reflow roots.

CPU was standing at 3% (and the ticker was working) until I crashed.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch, v. 3

I think I got the logic a little wrong regarding the case of a block that's the
target of an incremental reflow, and this should fix it.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: reflow roots hack, v. 1

Here's a slightly more realistic reflow-roots patch.  I've only tested this for
about 2 minutes, though.  I'd be curious to know if this also helps the time.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 86356 [details] [diff] [review]
reflow roots hack, v. 1

The nsCSSFrameConstructor.cpp change within this patch is really an insufficent
attempt to fix a tiny piece of bug 149203.

Comment 21

[Doron Rosenberg (IBM)]

adding topembed

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm going to attach replacements for both of the patches shortly...

Comment 23

[Yuying Long]

Add nsbeta1 keyword.

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: extra absolute reflow patch, v. 4

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: reflow roots hack, v. 2

We'd really also want to fix bug 149203, though, even if this works.

Comment 26

[Simon Montagu :smontagu]

Comment on attachment 86445 [details] [diff] [review]
reflow roots hack, v. 2

I'm afraid neither this nor the previous version seems to have any perceptible
effect on the CPU usage.

Comment 27

[Winnie Lam]

*** Bug 148825 has been marked as a duplicate of this bug. ***

Comment 28

[Winnie Lam]

*** Bug 145152 has been marked as a duplicate of this bug. ***

Comment 29

[Winnie Lam]

This bug marked as blocker for 147975 because it affects the loading of 
http://home.netscape.com/apple.adp, which is now the default chimera home page.
 Chimera bugs 145152 and 148825 were originally filed for this problem, and have
been marked as dupes of this bug.

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Taking bug.

Comment 31

[Chris Waterson]

Comment on attachment 86443 [details] [diff] [review]
extra absolute reflow patch, v. 4

sr=waterson

Comment 32

[John Morrison]

I've tried attachment 86443 [details] [diff] [review] in branch and trunk builds on win2k (pulled today).
Without the patch, I was at almost 100% cpu viewing home.netscape.com.
With the patch 
  (case A) branch and trunk run at about 30% cpu, dropping to 10% cpu when the 
           window is completely covered; 
  (case B) trunk has been observed to drop to 0% cpu, but this comes and goes.
           I haven't (yet) seen this occur in the branch, but that may just
           be chance (but perhaps it's because nsBlockFrame.cpp on the 
           branch has other, significant differences from the trunk version)
           

Comment 33

[John Morrison]

*** Bug 150636 has been marked as a duplicate of this bug. ***

Comment 34

[kinmoz]

Comment on attachment 86443 [details] [diff] [review]
extra absolute reflow patch, v. 4

r=[e-mail]

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Primary fix (attachment 86443 [details] [diff] [review]) checked in to trunk 2002-06-11 20:21 PDT.

Comment 36

[Brian Ryner (not reading)]

Attachment: patch against the 1.0 release/chimera branch

Looking for a review of this modified version of the patch to check into the
Chimera branch (pre-reflow-path).

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 87575 [details] [diff] [review]
patch against the 1.0 release/chimera branch

waterson just sanity-checked this, so I'm comfortable with your landing it on
the Chimera branch.

Comment 38

[Brian Ryner (not reading)]

checked into CHIMERA_M1_0_BRANCH.

Comment 39

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I just checked (at valeski's request) an optimized mfcembed build with and
without the patch (based on 6/13 evening trunk, by backing out the patch in that
tree).  With the patch, I was seeing 0%-1% CPU on home.netscape.com, and without
the patch I was seeing about 20% CPU on home.netscape.com.  This was on a 1.5GHz
Win2KPro machine.

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to MOZILLA_1_0_BRANCH, 2002-06-20 20:32 PDT.

Filed bug 153273 for investigation of remaining performance problems on
http://home.netscape.com/ and marking this bug fixed since the keywords, etc.,
don't really apply any longer, and since it's cleaner to have one bug per
problem and this bug is already quite messy.

Comment 42

[Jaime Rodriguez, Jr.]

postumus adt1.0.1+ :-(

Comment 43

[Ivan Eisen]

Should this have perf as a keyword?

Comment 44

[Kjell Andersson]

My browser:Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020716

www.netscape.com gives my cpu (450 MHz) a 45 percent workload. When I uncheck
Javascript to hold the CNN ticker, the percentage drops to 5-8. IE6 demands 8
percent with the ticker running.I suggest the bug needs some more consideration.

Comment 45

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Bug 153273 covers further performance work.