Closed
Bug 186442
Opened 22 years ago
Closed 11 years ago
"snowfall" script causes browser to slow to a crawl
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: danny, Unassigned)
References
()
Details
(Keywords: perf, testcase)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 Chimera/0.6+
When Chimera attempts to load the new "Snow fall" script at
http://www.southparkx.net, the browser becomes unresponsive and eventually locks
up to a standstill (with the spinning hard disc platter cursor).
While I understand this is probably a bad script, there shouldn't be any script
or site that can bring the browser to a complete standstill and require a
force-quit (which usually requires the cache files to be deleted before it'll
load past the splash screen again).
Reproducible: Always
Steps to Reproduce:
1. Go to http://www.southparkx.net
2. Wait for the "snow" script to start
3. There is no step three.
Actual Results:
The site layout loads, but a few seconds later the snow script tries to load and
then results in the lockup
Expected Results:
Loaded the page and script without a lockup, or just skip over the script if
it's bad
Comment 1•22 years ago
|
||
Using 2002122004 I have similar results. Browser goes into a loop apparently
where is is unresponsive for about 5 seconds, then draws a frame of snow
falling, repeating that over and over. I was able to switch tabs, very slowly,
so events are still getting through. I'm on tibook/400.
Renamed, confirmed. (Was: A complete browser lockup happens when loading
southparkx.net)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: A complete browser lockup happens when loading southparkx.net → "snowfall" script causes browser to slow to a crawl
Comment 2•22 years ago
|
||
This happens in Mozilla as well
->sfraser
Assignee: saari → sfraser
Component: General → Layout
Product: Chimera → Browser
Version: unspecified → Trunk
Comment 3•22 years ago
|
||
Comment 5•22 years ago
|
||
Comment 6•22 years ago
|
||
(Note that I removed the indentation in the sampler data down to
CanvasFrame::Reflow() for easier viewing), and reduced file size.)
Comment 7•21 years ago
|
||
Largely dependent on bug 157681, also bug 34887.
Comment 8•21 years ago
|
||
One interesting thing I found on this particular testcase is that it has all
these calls to window.innerWidth, document.body.clientHeight, pageXOffset, etc,
etc to calculate the rect it's ok for the snowflakes to be in. All of these end
up calling FlushPendingNotifications, which naturally flushes all of our pending
reflows. Which means that we do a reflow separately for each snowflake,
essentially.
I'm not sure what we can do about that exactly, but we should think about it...
For the sake of experiment I replaced all those calls with harcoded values for
the page scroll position, width, height, etc. Time spent inside reflow dropped
from 25% of total time to about 10%. So trying to improve on this would be a
big win on this page....
After that, the biggest problem was that we reresolve style on everything twice
(once for top, once for left). Bug 230170 may help there.
Depends on: 230170
Duplicate of bug 139986.
Comment 10•18 years ago
|
||
As a matter of fact, no. It's not. As you can tell from a simple look at the profiles.
Updated•16 years ago
|
Assignee: sfraser_bugs → nobody
Comment 11•16 years ago
|
||
The attached testcase runs pretty smooth for me here on a rather underpowered system w/ 3.1b2. Maybe time for a new profile and/or a WFM?
Comment 12•16 years ago
|
||
So on a current build on Mac, I see something like this:
Paint event processing (painting and various widget stuff, including a bunch of background painting): 42%
Running the timeout JS: 27%
Reflow event processing: 9.4%
Restyle event processing: 8.2%
dtrace_get_cpu_stack_top: 8% (might be profiling artifact, or might be kernel or
driver code running)
The 27% running the JS breaks down as:
Setting style.top/left: 9%
Getting various properties on Window (scrollX, scrollY, innerWidth, innerHeight): 9%. A lot of xpconnect overhead hear, js_ComputeThis fun with wrappers, etc. EnsureSizeUpToDate() actually takes some time here, mostly in getting the actual parent and in flushing. Maybe we should fast-path some of this stuff somehow?
The rest of thet time is spent in js_ValueToString (3%), js_Interpret itself (3%), and various other stuff (3% or so).
Comment 13•16 years ago
|
||
I'd attach the shark profile, but it's too big for bugzilla. :(
Updated•15 years ago
|
QA Contact: winnie → layout
Comment 14•12 years ago
|
||
On Firefox 17, the testcase runs using 3% of CPU. Nightly uses 12%.
Comment 15•12 years ago
|
||
http://www.southparkx.net/ is down, but https://bugzilla.mozilla.org/show_bug.cgi?id=824952 links to another snow script that lags the whole browser. I don't know whether it uses the same technique, though.
Comment 16•11 years ago
|
||
The testcase runs OK for me on Windows 7, with and without HWA. Tested on Beta and Nightly (25 and 27).
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•