Closed Bug 63530 Opened 24 years ago Closed 23 years ago

Pages with large tables (?) nearly peg CPU

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: owen-mozilla, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: perf)

Attachments

(1 file)

jprof profile of what happens while CPU is pegged
415.56 KB, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17 i686)
BuildID:    200122021

I've noticed that pages on the home theater forum use a lot of CPU
power, close to pegged.  For topics with few posts, the impact is minimal to
none.  For large topics however (like the URL I've posted), the CPU utilization
quickly jumps.  The page need not be scrolling or loading.  It just sits there
and chews cycles

Reproducible: Always
Steps to Reproduce:
Open a HTF page that has lots of replies

Actual Results:  Watch CPU usage skyrocket.

Expected Results:  CPU usage shouldn't do that.

I checked the source for <STYLE> tags, and didn't find anything.  None of the
other bugs with the word "CPU" in the summary seemed to apply.
Verified.
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2000121908 M18 Trunk Build

Topped off at a cool 90.5% of CPU usage.

Not sure its the tables though because i dont have a debug version. Anyone anyone?
Marking NEW to get someone to look at it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
A jprof profile shows lots of time spent in reflow and in image code.  This
seems like there's some sort of infinite loop between image loading and
reflows.  It doesn't happen every time I load the page, but most of them.
I think this is related to bug I remember seeing about animated gifs redrawing
the whole page, or something like that. If I hit escape to stop animated gifs,
the CPU usage immediately drops to nil again.  If someone could find that
original bug, this is probably a dupe.  
Reassigning to myself.
Assignee: clayton → karnaze
Target Milestone: --- → mozilla0.9
Marc, based on Owen's comment, I'm reassigning to you, since you have a fix for 
part of the animated gif problem.
Assignee: karnaze → attinasi
Milestone shift --> Moz 0.8.1
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla0.8.1
I have checked in the fix for the animated gif reflow problem (bug 69534) - Need
to recheck this one...
BTW: the jprof looks a lot like bug 63750 - my guess is that this is the same 
problem that I tried to describe in that bug. In any case, it is going away as 
soon as the new imagelib lands.
Depends on: 63750
URL is no longer available. Does anybody have a cached copy or another URL to test?
I originally brought it up as part of (bug 61985), but
http://dealnews.com/view.html?d2=7 seems to use lots of CPU during load. I'm not
sure if it's definitely related to this bug.
most any lengthy thread on the Home Theater Forum exhibits this bug.  Here are a
few: http://www.hometheaterforum.com/uub/Forum14/HTML/036182.html,
http://www.hometheaterforum.com/uub/Forum14/HTML/036101.html,
http://www.hometheaterforum.com/uub/Forum9/HTML/004584.html

Those were all randomly selected, and the first three I picked.  I want to
stress that pressing escape brings CPU time back to null.  For this reason I
still think it must be an animated gif issue.  What else does pressing escape do
once the page has loaded?
I'm seeing this behavior exactly. I wonder if it is because of the gifs as
backgrounds... I have a patch for another bug (bug 63750) that may take care of
this, I'll check it out.
The patch for bug 63750 makes this a LOT better, but there is still some CPU
used until I press escape. I'll run jprof or quantify after 63750 is checked in
to see what is left.
Hey Chris, wanna check this out since your table reflow improvements are in now?
The table changes have no impact after your patch for bug 63750. Breaking in the 
debugger with that patch never shows a reflow stack. Maybe Necko is spinning.
Moving to mozilla0.9
Target Milestone: mozilla0.8.1 → mozilla0.9
This is much better since bug 63750 has been fixed. I'll quantify and see what 
is using up the remaining 10% cpu on my NT box.
Moving off to Mozilla 0.9.1 since the vast majority of the performance problems 
have been resolved.
Target Milestone: mozilla0.9 → mozilla0.9.1
--> P3
Priority: -- → P3
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
By mandate, moving non-crashers and non-dataloss bugs out
Target Milestone: mozilla0.9.2 → mozilla1.0
Ths page does not exist anymore.
Though I didn't file the original bug report, this url may be a suitable
replacement:
http://www.hometheaterforum.com/uub/Forum15/HTML/025905.html
worksforme 2001081703 win32 on win2k
They may have changed their page again - I see no animated backgrounds, not any
other anims to speak of.  CPU usage once loaded is nil.

Someone needs to find another example of this if more investigation can occur.
Resolving as WFM
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Target Milestone: mozilla1.0 → Future
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: