performance.now() perf is hurt by looking up 'performance' |
|||
Issue descriptionBug was reported by Justin Rogers in: https://twitter.com/JustRogDigiTec/status/794664508899749888 The repro code is here: https://jsfiddle.net/tu0muno1/ Basically it just calls performance.now() in one loop, and in another loop calls p.now() where "var p = performance;". Typical results are: Peformance.now() cached 223.755 Performance.now() not cached 370.04499999999996 Date.now() cached 114.29500000000019 Date.now() not cached 114.21499999999992 So, Performance.now() has worse performance than Date.now(), and it is even worse if 'performance' is not cached in a variable. Version: 54.0.2840.87 m OS: The issue exists on both Windows and Linux. However the issue only matters on Windows because the performance of performance.now() and Date.now() on Linux are significantly worse (crbug.com/502205) so the overhead of the non-cached lookup and the extra cost of Performance.now() is a smaller ratio. Typical Linux results are: Peformance.now() cached 1667.4150000000002 Performance.now() not cached 1939.0500000000004 Date.now() cached 1442.3200000000006 Date.now() not cached 1456.6800000000003
,
Nov 17 2016
Since this seems to be a bindings issue, would you mind triaging further Kentaro?
,
Nov 17 2016
Date.now() is implemented in JS. performance.now() needs to go through V8 <=> Blink bindings. So I won't be surprised that performance.now() is much slower than Date.now(). However, I agree that we should make it faster.
,
Dec 3 2017
Is this bug being addressed? The performance is painfully slow. 10X slower than Firefox. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dtapu...@chromium.org
, Nov 10 2016Components: Blink>JavaScript