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...
Comment 9•17 years ago
|
||
...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
•