Bug 3782
Summary: | Animation via <div> styling could be faster | ||
---|---|---|---|
Product: | WebKit | Reporter: | Ian 'Hixie' Hickson <ian> |
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | bfulgham, emacemac7, gsherloc, ian, robert, simon.fraser |
Priority: | P3 | ||
Version: | 412 | ||
Hardware: | All | ||
OS: | OS X 10.4 | ||
URL: | http://hixie.ch/tests/adhoc/perf/video/003.html |
Ian 'Hixie' Hickson
This is a silly performance test, but Safari is quite slow.
TESTCASE
http://hixie.ch/tests/adhoc/perf/video/003.html
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Maciej Stachowiak
I sampled with Shark. A huge chunk of the time on this test is spent in the JS garbage collector. I think this
is really a JavaScript issue, not CSS.
Ian 'Hixie' Hickson
Weird. What is it garbage collecting?
Eric Seidel (no email)
I would say these are more "edgecase" or "minor performance complaints" instead of "serious performance
complaints".
P3
http://webkit.opendarwin.org/quality/bugpriorities.html
Elliott Sprehn
(In reply to comment #3)
> I would say these are more "edgecase" or "minor performance complaints" instead
> of "serious performance
> complaints".
>
> P3
>
> http://webkit.opendarwin.org/quality/bugpriorities.html
>
Seems to me this should be bumped back up to P2 as per the second criteria: "Serious performance complaints."
Safari is painfully slow when loading that page, and worse the whole browser locks up while the animation runs. UI elements either don't respond or they're delayed several seconds. Seems to me if the GC can't be improved then an "Unresponsive Script" dialog that allows stopping the script should be added.
Doing Apple+A, Apple+C on that page (copy all) also causes a beachball for a couple seconds which isn't ideal.
On a Side Note of Interesting Numbers:
Safari 2.0 (latest)
Elapsed wall-clock time: 34725ms (ideal: 640ms).
Elapsed non-idle time: 34085ms (ideal: 0ms).
Speed: .43fps (ideal: 25.00fps).
Nightly:
Elapsed wall-clock time: 26485ms (ideal: 640ms).
Elapsed non-idle time: 25845ms (ideal: 0ms).
Speed: 0.57fps (ideal: 25.00fps).
Firefox 2.0.2:
Elapsed wall-clock time: 12293ms (ideal: 640ms).
Elapsed non-idle time: 11653ms (ideal: 0ms).
Speed: 1.22fps (ideal: 25.00fps).
What browser was Hixie testing in that he got 640ms/25fps?
(System Specs for Reference: 1.33Ghz G4 1.25GB Powerbook 12")
Gavin Sherlock
I ran this multiple times, both in Safari 3.2.1, and the latest nightly (r 40931), and it seems the nightly is actually slower, but ~0.5 frames per second, though it would be useful to have a test that runs for longer to get some more accurate timings.
Simon Fraser (smfr)
I'm betting this is not limited by JS, but by layout and rendering.
Robert Hogan
Chrome 27 (WebKit r147273):
Elapsed wall-clock time: 1562ms (ideal: 640ms).
Elapsed non-idle time: 922ms (ideal: 0ms).
Speed: 9.60fps (ideal: 25.00fps).
FF 21:
Elapsed wall-clock time: 3332ms (ideal: 640ms).
Elapsed non-idle time: 2692ms (ideal: 0ms).
Speed: 4.50fps (ideal: 25.00fps).
Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.15:
Elapsed wall-clock time: 995ms (ideal: 640ms).
Elapsed non-idle time: 355ms (ideal: 0ms).
Speed: 15.08fps (ideal: 25.00fps).
Are we bad enough on this test to keep this bug open?
Brent Fulgham
All major browsers seem to be about the same on this test now (Safari is fastest, though Chrome and Firefox are within the noise).