RESOLVED FIXED 237303
Fix Speedometer's setTimeout throttling issue
https://bugs.webkit.org/show_bug.cgi?id=237303
Summary Fix Speedometer's setTimeout throttling issue
Yusuke Suzuki
Reported 2022-02-28 19:04:59 PST
Fix Speedometer's setTimeout throttling issue
Attachments
Patch (11.71 KB, patch)
2022-02-28 19:09 PST, Yusuke Suzuki
ggaren: review+
Yusuke Suzuki
Comment 1 2022-02-28 19:09:37 PST
Yusuke Suzuki
Comment 2 2022-02-28 19:09:42 PST
Chris Dumez
Comment 3 2022-02-28 19:14:38 PST
Comment on attachment 453463 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=453463&action=review > PerformanceTests/Speedometer/resources/benchmark-runner.js:149 > + window.requestAnimationFrame(function () { Is this part of the change really needed? This part would impact the score and it is therefore unfortunate. I would have hoped that the outer requestAnimationFrame would have been enough to avoid reaching the max nesting limit and cause throttling.
Yusuke Suzuki
Comment 4 2022-02-28 19:20:05 PST
Comment on attachment 453463 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=453463&action=review >> PerformanceTests/Speedometer/resources/benchmark-runner.js:149 >> + window.requestAnimationFrame(function () { > > Is this part of the change really needed? This part would impact the score and it is therefore unfortunate. I would have hoped that the outer requestAnimationFrame would have been enough to avoid reaching the max nesting limit and cause throttling. This is necessary to reset nesting level, and 1. This affects on the score, but just because we reset nesting level, and that's the intent of this change. 2. window.requestAnimationFrame itself is not included in the measurement since it is done outside of measurement (see sync-time duration and async-time duration. this call is not included).
Yusuke Suzuki
Comment 5 2022-02-28 19:20:41 PST
(In reply to Yusuke Suzuki from comment #4) > Comment on attachment 453463 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=453463&action=review > > >> PerformanceTests/Speedometer/resources/benchmark-runner.js:149 > >> + window.requestAnimationFrame(function () { > > > > Is this part of the change really needed? This part would impact the score and it is therefore unfortunate. I would have hoped that the outer requestAnimationFrame would have been enough to avoid reaching the max nesting limit and cause throttling. > > This is necessary to reset nesting level, and > 1. This affects on the score, but just because we reset nesting level, and > that's the intent of this change. > 2. window.requestAnimationFrame itself is not included in the measurement > since it is done outside of measurement (see sync-time duration and > async-time duration. this call is not included). sync-time region and async-time region
Yusuke Suzuki
Comment 6 2022-02-28 19:21:23 PST
Comment on attachment 453463 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=453463&action=review > PerformanceTests/Speedometer/resources/benchmark-runner.js:146 > var endTime = now(); async test's measurement is finished at this point. So, window.requestAnimationFrame is unrelated to the measurement except for reseting the nesting level.
Geoffrey Garen
Comment 7 2022-03-01 10:07:56 PST
Comment on attachment 453463 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=453463&action=review r=me I think Yusuke resolved Chris's comment; please correct me if not. > PerformanceTests/Speedometer/resources/benchmark-runner.js:57 > + if (element) { > + window.requestAnimationFrame(function () { > + return promise.resolve(element); > + }); > + return; > + } The change to _runTest (below) ensures that each test ends with zero timer nesting level. I think the purpose of this change is to ensure that each test also begins with zero timer nesting level? Seems like a reasonable solution. But I'm curious, to help with my own mental model: Did you discover a specific case where just one of these changes or the other alone was insufficient?
Chris Dumez
Comment 8 2022-03-01 10:08:49 PST
(In reply to Geoffrey Garen from comment #7) > Comment on attachment 453463 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=453463&action=review > > r=me > > I think Yusuke resolved Chris's comment; please correct me if not. Yes. All good.
Yusuke Suzuki
Comment 9 2022-03-01 11:21:07 PST
Comment on attachment 453463 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=453463&action=review Thanks! >> PerformanceTests/Speedometer/resources/benchmark-runner.js:57 >> + } > > The change to _runTest (below) ensures that each test ends with zero timer nesting level. > > I think the purpose of this change is to ensure that each test also begins with zero timer nesting level? > > Seems like a reasonable solution. But I'm curious, to help with my own mental model: Did you discover a specific case where just one of these changes or the other alone was insufficient? I think waitForElement can be used because it is not inside _runTest (this is helper function waitForElement), so even if it is not used (I think currently it is always used), this change can ensure that setTimeout of this function will not affect the following test suite's run.
Yusuke Suzuki
Comment 10 2022-03-01 11:38:40 PST
Note You need to log in before you can comment on or make changes to this bug.