WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Yusuke Suzuki
Comment 1
2022-02-28 19:09:37 PST
Created
attachment 453463
[details]
Patch
Yusuke Suzuki
Comment 2
2022-02-28 19:09:42 PST
<
rdar://problem/89444976
>
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
Committed
r290664
(
247936@trunk
): <
https://commits.webkit.org/247936@trunk
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug