Closed
Bug 383351
Opened 17 years ago
Closed 11 years ago
A hang or very high CPU usage on this page
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ria.klaassen, Unassigned)
References
()
Details
(Keywords: perf, regression)
Attachments
(2 files, 2 obsolete files)
When I go to the URL in the URL field I get a hang or a high CPU usage.
Before bug 300030 it was about 30-35% and after bug 300030 85-100%.
Comment 2•17 years ago
|
||
Thanks for attaching the page, Ria.
I've minimized that page to this, thus far.
I still see a cpu increase when testing between 2006-12-07 and 2006-12-08 builds. (unfortunately, I have difficulty with quantifying it with a timeout, that would make minimizing easier)
Comment 3•17 years ago
|
||
So is this Windows-only? I don't see any CPU usage on Linux on that testcase once it finishes loading...
Comment 4•17 years ago
|
||
Sorry, should have said it, you need to click on the runscroller button to begin testing.
Comment 5•17 years ago
|
||
Hmm. Yeah, a profile doesn't show anything unexpected... about half the time spent in reflow, half elsewhere...
Comment 6•17 years ago
|
||
Cut out a bunch of the JS, didn't touch the HTML
Attachment #267316 -
Attachment is obsolete: true
Attachment #269522 -
Attachment is obsolete: true
Updated•17 years ago
|
OS: Windows XP → All
Updated•17 years ago
|
Keywords: helpwanted
This is a somewhat minimized testcase. I didn't try to change the javascript. Press the "runscroller"-button for the test.
The CPU usage doesn't jump extremely high when you remove one of the following:
- the 'height="585"' of the <td>
- the 'style="width: 760px;"' of the <div id="ticker">
- move the entire '<div id="ticker">' out of the <table>
Comment 8•17 years ago
|
||
I just tried profiling this on Mac, and we spend all our time painting. Removing the height from the table cell drops CPU usage from 40% to 20% or so.
I wonder whether the height matters just because we end up invalidating a bigger area or something? I still wouldn't expect the repaint here to be all that expensive here...
...could also be triggering special height reflow, requiring an extra pass (and perhaps additional invalidation resulting from the oscillation between the two results).
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
Comment 10•15 years ago
|
||
(In reply to comment #7)
> Created an attachment (id=292949) [details]
> Minimized testcase
>
> This is a somewhat minimized testcase. I didn't try to change the javascript.
> Press the "runscroller"-button for the test.
>
> The CPU usage doesn't jump extremely high when you remove one of the following:
> - the 'height="585"' of the <td>
> - the 'style="width: 760px;"' of the <div id="ticker">
> - move the entire '<div id="ticker">' out of the <table>
ranges 5-15% cpu for me with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090621 Minefield/3.6a1pre (.NET CLR 3.5.30729)
Comment 11•11 years ago
|
||
Works for me using testcases that had been attached here using Lastest Nighty 25:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130730 Firefox/25.0
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: helpwanted,
qawanted
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•