Closed Bug 223613 Opened 22 years ago Closed 11 years ago

Viewing page gobbles 100% CPU

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: tulipawn, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

Diff against page which lowers CPU usage
29.45 KB, patch
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031024 Firebird/0.7+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031024 Firebird/0.7+ Upon opening the page above, CPU usage goes up to 100% and stays there for the time the page is kept open. The processor is an Athlon XP 2000+ so surely something must be wrong here. Reproducible: Always Steps to Reproduce: 1. 2. 3.
The page is resetting the background position style on <body> every 64 milliseconds (which requires a full-page repaint, as well as a full style reresolve on everything in the document). There is hardly a good way to make this blazing fast... On my P3-733 system, I see Mozilla taking about 50% cpu and X another 15-20% (according to top). Are you actually seeing 100% usage? Or are you seeing some sort of "usage bar" at 100%? If so, what's top showing?
On Windows XP SP1 (Mozilla 1.5) I'm seeing between 50-65% (fluctuating).
Issue duplicated in Internet Horror 6 SP1 -- Windows 2000 SP 4.... I vote the site is coded like shyte....
Yep. I would suggest closing this bug. The remaining issue is why the CPU usage was 100% for the reporter. As bz suggests, it should not be that high.
Well, before anyone actually closes anything I'm going to do a profile to see where we spend what time we spend... See whether that brings up anything interesting.
Lets see: 1. Plugin. <insert plugin CPU usage here> 2. Animated Background. Im not a mozilla src expert, but perhaps possibility of thread bottleneck on older CPU's 3. Non complaint CSS: http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.btinternet.com%2F%7Eappleby.manor%2Fandy%2Fsimon%2Fsimmain%2Fwalkthu%2Fwalk2.htm&warning=1&profile=css2&usermedium=all what is "table-border-color-light" 4. Non compliant HTML I vote 2 (Animated background) as cause. Tech Evang anyone?
So in case anyone cares, of the 12809 total profiler hits in a run just now, 3545 were under nsViewManager::RenderViews (called mostly from nsWindow::DoPaint) and almost all of the rest (8569) were under nsFrameManager::ReResolveStyleContext. Time under ReResolveStyleContext was split as follows (all numbers are number of hits under callee): 2869 CaptureChange 2267 nsPresContext::ResolveStyleContextFor 1843 nsPresContext::ProbePseudoStyleContextFor 181 nsStyleContext::Destroy 153 nsContainerFrame::FirstChild 125 nsPresContext::ResolveStyleContextForNonElement 106 nsPresContext::ResolvePseudoStyleContextFor 98 UndisplayedMap::GetFirstNode and a bunch more small fry, plus 324 hits in the function itself. Most of the time in CaptureChange(), unsurprisingly, is in nsStyleContext::CalcDifference and about 2/3 of that is in GetStyleData, font data being the biggest culprit (but only about 1/3 of the total CaptureChange time). nsPresContext::ProbePseudoStyleContextFor time is split about 2-1 between StyleSetImpl::FileRules and RuleProcessorData::RuleProcessorData nsPresContext::ResolveStyleContextFor time is split about 16-2-1 between StyleSetImpl::FileRules, RuleProcessorData::RuleProcessorData, and StyleSetImpl::GetContext The only thing I see here that's a little weird is the comparatively large amount of time spent in RuleProcessorData::RuleProcessorData when probing for a pseudo-style... that seems a bit odd.
Matthew, no need to vote. Simply making a local copy of the page and 3 minutes of testing shows that the animated background is indeed what's taking up cpu time...
To be precise CPU usage is split roughly 75/25 between X and Mozilla. Occasioanally it's a little less than 100% but it never goes under 90%.
Piotr, that sounds like the problem lies in your X server... your Mozilla CPU usage is about comparable to mine (accounting for the difference in processor speed), but your X server is taking up a lot more CPU than mine is.
Indeed, I might have a problem with nvidia binary drivers as I checked the same page with Mozilla on another computer (a lowly P166MMX) and the ratio was reversed, i.e. 75% occupied by Mozilla and about 10% taken by X. So even though I didn't point to the CPU eating component in the bug's summary it looks like it can go both ways depending on the drivers.
Problem also appearing on 2003102104, even on my 1.8GHz P4 lappy (with SIS650 intergrated graphics). I've saved a copy of the page and had a go at manipulating it: - Removing background animation: 0% percent decrease. - Removing entire contents of right table cell: 20% decrease.
Removing the right cell in it's entireity fixes this.
> - Removing background animation: 0% percent decrease. How did you test this, exactly?
Could this be because the animation is behind the table? Perhaps rendering that is what's causing this to happen? To busy to test now, but I'm curious if it lowers if the table border is set to 0, or if the table is just removed. Lastly, if that main td's backround wasn't black (where the text is).
> How did you test this, exactly? Test is probably the wrong word. taskmgr still reports high CPU usage out of mozilla.exe with or without background. robert: animation behind table doesn't appear to be the problem. It appears to be the table itself. See my diff.
Please do read the profile before commenting... The slow part from Mozilla's point of view is reresolving style on every single element on the page every 64ms. Painting is comparatively cheap (again, from mozilla's point of view; how much CPU your X server takes for the paint is a separate issue). So yes, removing all the content will make things "faster".
Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
The same behaviour is still demonstrated with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050922 Firefox/1.6a1
To style system, I guess. Not confirming, because I'm not sure there is a real issue here (one that can be resolved without a full style system redesign, at least).
Assignee: general → dbaron
Component: General → Style System (CSS)
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Assignee: dbaron → nobody
QA Contact: ian → style-system
No longer blocks: 724031
The URL no longer exist. Nothing else can be done now, unfortunately.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: