Closed Bug 186442 Opened 22 years ago Closed 11 years ago

"snowfall" script causes browser to slow to a crawl

Categories

(Core :: Layout, defect)

defect
Not set
critical

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
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
This happens in Mozilla as well ->sfraser
Assignee: saari → sfraser
Component: General → Layout
Product: Chimera → Browser
Version: unspecified → Trunk
Attached file Testcase (deleted) —
Probably related to bug 157681.
Keywords: perf
(Note that I removed the indentation in the sampler data down to CanvasFrame::Reflow() for easier viewing), and reduced file size.)
Largely dependent on bug 157681, also bug 34887.
Depends on: 34887, 157681
Keywords: testcase
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
Depends on: 144072
Depends on: 245131
OS: MacOS X → All
Hardware: Macintosh → All
Duplicate of bug 139986.
As a matter of fact, no. It's not. As you can tell from a simple look at the profiles.
Assignee: sfraser_bugs → nobody
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?
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).
I'd attach the shark profile, but it's too big for bugzilla. :(
QA Contact: winnie → layout
On Firefox 17, the testcase runs using 3% of CPU. Nightly uses 12%.
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.
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.

Attachment

General

Created:
Updated:
Size: