What is the point of this throttling given the workarounds (postMessage?)
or maybe postMessage is going to be throttled?
I've used this to make something that takes a long time not freeze the
browser
const wait = _ => new Promise(resolve => setTimeout(resolve));
for (many-operations) {
doOperation();
await wait();
}
When I found out setTimeout slowed things down too much I first changed it
to only call wait every N operations. That sucked since what to set N do
was ambiguous. I thought about changing to only calling `wait` if so much
time had passed. Eventually I just changed `wait` call `postMessage` and
resolve on receiving the message. The throttling disappeared, which made me
wonder what the point of the throttling was in the first place given it's
trivial to workaround.
On Mon, Feb 20, 2023 at 9:56 AM Yoav Weiss <[email protected]> wrote:
>
>
> On Mon, Feb 20, 2023 at 6:46 PM Etienne Pierre-doray <
> [email protected]> wrote:
>
>> Did the experimentation show any positive or negative impact on real-life
>>> content?
>>>
>> On windows, the only significant impact we saw in the field is a
>> regression on Input Delay (Page Load), 5.20% at 95th %ile. No improvement
>> otherwise, so I don't see any benefits of going forward with this anymore.
>>
>> Does the current spec match reality? (where this value is UA defined)
>>>
>> No. The spec
>> <https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html>
>> seems to say "if > 5", Blink and Gecko do "if >= 4" which is off by 2 (
>> crbug.com/1108877).
>> WebKit used to do "if >= 5", but recently changed
>> <https://sourcegraph.com/github.com/WebKit/WebKit/-/commit/786e3e0b252e38fb01c8db97a94d52cb0f57891e?visible=6>
>> it to "if >= 10".
>>
>> where does Gecko stand on this
>>>
>> I tested this with the code snippet from crbug.com/1108877. This gives
>> me the same result as Chrome.
>>
>> If not, maybe that's the easiest way to provide clarity on this point, if
>>> WebKit is shipping one thing and Chromium does another.
>>>
>> Does this mean changing the spec to make it looser re. the threshold
>> value?
>>
>
> +Domenic Denicola <[email protected]> can correct me if I'm wrong here,
> but it seems like we may want to make that value implementer-defined.
> Alternatively, we can modify the spec to match what Chrome and Gecko are
> doing, and try to convince WebKit folks to align.
>
>
>>
>>
>> On Mon, Feb 20, 2023 at 2:38 AM Yoav Weiss <[email protected]>
>> wrote:
>>
>>> Did the experimentation show any positive or negative impact on
>>> real-life content?
>>>
>>> On Thu, Feb 16, 2023 at 10:18 PM François Doray <[email protected]>
>>> wrote:
>>>
>>>> The change to the nesting level at which 4ms clamping kicks in
>>>> (MaxUnthrottledTimeoutNestingLevel) never shipped, because Speedometer 2.1
>>>> is not affected by it like Speedometer 2.0 was. However, WebKit did
>>>> implement this change:
>>>> https://sourcegraph.com/github.com/WebKit/WebKit/-/commit/786e3e0b252e38fb01c8db97a94d52cb0f57891e
>>>> and Chrome updated its documentation:
>>>> https://github.com/GoogleChrome/developer.chrome.com/commit/b6529b1cc8fdd9b2cb3496f446ee332207ab40b2
>>>> even though it did not ship the change.
>>>>
>>>> What do Blink owners recommend as next step for this?
>>>>
>>>
>>> Does the current spec match reality? (where this value is UA defined)
>>> If not, maybe that's the easiest way to provide clarity on this point,
>>> if WebKit is shipping one thing and Chromium does another. Also - where
>>> does Gecko stand on this?
>>>
>>>
>>>> On Wednesday, May 25, 2022 at 2:59:30 PM UTC-4 Etienne Pierre-doray
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm sharing an update with results of the experiments over 21 days on
>>>>> Chrome Beta M102.
>>>>>
>>>>> The results below are mostly small percentages changes, and the finch
>>>>> guidelines
>>>>> <https://groups.google.com/a/google.com/g/chrome-catan/c/ZL-FCrq-Q40/m/ntQk88UFBgAJ?utm_medium=email&utm_source=footer>
>>>>> says to trust results on Stable. Given no issue have been raised
>>>>> AFAIK I would like to roll out a 1% finch experiment on Stable and I'm
>>>>> wondering what would be the required steps to do this (besides
>>>>> flipping boxes on the launch crbug.com/1298967
>>>>> <http://crbug.com/1298967>) without amending what the spec
>>>>> <https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html>
>>>>> says just yet.
>>>>>
>>>>>
>>>>> The experiment MaxUnthrottledTimeoutNestingLevel
>>>>> <https://docs.google.com/document/u/1/d/1boT0k8BQjl7mXXzvI9SdN4XJPSza27vE8T0CNxmMhCI/edit>
>>>>> has been running on canary/dev/beta M101 and M102.
>>>>>
>>>>> Another experiment SetTimeoutZeroWithoutClamping
>>>>> <http://crbug.com/1263190> which removes setTimeout(,0) clamping to 1
>>>>> ms is running at Enabled(25%) and Default(50%) on Beta. Analyzing the
>>>>> results for both experiments together makes sense because our goal is to
>>>>> avoid delayed tasks for immediate setTimeout()s.
>>>>>
>>>>> MaxUnthrottledTimeoutNestingLevel (50% enabled / 50% control) +
>>>>> SetTimeoutZeroWithoutClamping (Default + Enabled is 75%)
>>>>>
>>>>> Finch Win
>>>>> <https://uma.googleplex.com/p/chrome/variations?sid=d5a6fc8df0a156c8cf12f5271ee633ac>
>>>>> ,
>>>>>
>>>>> No impact on Guiding Metrics
>>>>>
>>>>> Finch Mac
>>>>> <https://uma.googleplex.com/p/chrome/variations?sid=4720de277607785af52a737fcf5dad82>
>>>>>
>>>>> -15.85% Time To Paint For Each Ad Frame @ 95%ile 2-diamonds
>>>>>
>>>>> Finch Android
>>>>> <https://uma.googleplex.com/p/chrome/variations?sid=61617c1a3a8be13ab86afd5efd47eac7>
>>>>>
>>>>> -1.78% First Input Delay @ 99%ile 1-diamonds
>>>>>
>>>>> -0.74% Time to Largest Contentful Paint @ 99%ile 1-diamonds
>>>>>
>>>>> -0.79% Cumulative Layout Shift @ 95%ile 2-diamonds
>>>>>
>>>>> -1.45 / 1.26% Startup Time @ 95 / 99%ile 1 / 2-diamonds
>>>>>
>>>>> +1.93% Scroll Latency Count 1-diamonds
>>>>>
>>>>> +0.32% Memory: Renderer@ 50%ile 1-diamonds
>>>>>
>>>>> MaxUnthrottledTimeoutNestingLevel ignoring
>>>>> SetTimeoutZeroWithoutClamping
>>>>>
>>>>> Note: Results here are less interesting since our goal is to avoid
>>>>> delayed tasks for immediate setTimeout()s, which is only achieved under
>>>>> SetTimeoutZeroWithoutClamping.
>>>>>
>>>>> Finch Win
>>>>> <https://uma.googleplex.com/p/chrome/variations?sid=a67092052bb30ce06b7d71914f174a68>
>>>>>
>>>>> +1.73% Time to First Contentful Paint @ 95%ile 2-diamonds
>>>>>
>>>>> -1.28% Frame Drawing Interval @ 95%ile 1-diamonds
>>>>>
>>>>> -1.44% Startup Time @ 99%ile 1-diamonds
>>>>>
>>>>>
>>>>> Note: the downside of experimenting on Stable is that the intersection
>>>>> of both 1% experiments is very small and we probably won't be able to
>>>>> analyze results alongside before SetTimeoutZeroWithoutClamping ships
>>>>> (this should happen soon though).
>>>>>
>>>>>
>>>>> Maybe a console warning message if we hit the nesting level that we
>>>>>> plan to increase? I'm not sure how effective that would be in helping get
>>>>>> folks to try it.
>>>>>>
>>>>> I'm trying this out here
>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3668605>.
>>>>>
>>>>>
>>>>> On Wed, Mar 30, 2022 at 2:19 PM Scott Haseley <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Mar 30, 2022 at 10:41 AM Etienne Pierre-doray <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> What's the plan for finding sites this breaks? Monitor bug reports?
>>>>>>>> Or is there something more proactive we could do?
>>>>>>>>
>>>>>>> I'm thinking about bug reports and guardian metrics. shaseley@
>>>>>>> might have additional insight from running a similar experiment
>>>>>>> crbug.com/1263190
>>>>>>>
>>>>>>
>>>>>> Yeah that's what I was thinking; that's the approach we're taking for
>>>>>> removing setTimeout(0) 1 ms clamping. It would be helpful if devs could
>>>>>> try
>>>>>> this out and report issues (it's enabled behind a flag
>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/-TjeYs7shTQ/m/th-1ACvYDAAJ>).
>>>>>> Maybe a console warning message if we hit the nesting level that we plan
>>>>>> to
>>>>>> increase? I'm not sure how effective that would be in helping get folks
>>>>>> to
>>>>>> try it.
>>>>>>
>>>>>> On Wed, Mar 30, 2022 at 6:00 AM Yoav Weiss <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> LGTM to experiment M101-102 inclusive
>>>>>>>> Thanks for working on this!!
>>>>>>>> What's the plan for finding sites this breaks? Monitor bug reports?
>>>>>>>> Or is there something more proactive we could do?
>>>>>>>>
>>>>>>>> On Monday, March 28, 2022 at 9:36:30 PM UTC+2 Etienne Pierre-doray
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Contact [email protected]
>>>>>>>>>
>>>>>>>>> ExplainerNone
>>>>>>>>>
>>>>>>>>> Specification
>>>>>>>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>>>>>>>>
>>>>>>>>> Design docs
>>>>>>>>>
>>>>>>>>> https://docs.google.com/document/d/1boT0k8BQjl7mXXzvI9SdN4XJPSza27vE8T0CNxmMhCI
>>>>>>>>>
>>>>>>>>> Summary
>>>>>>>>>
>>>>>>>>> Increase the nesting threshold before which setTimeout(..., <4ms)
>>>>>>>>> start being clamped, from 5 to 100. setTimeout(..., 0) is commonly
>>>>>>>>> used to
>>>>>>>>> break down long Javascript tasks and let other internal tasks run,
>>>>>>>>> which
>>>>>>>>> prevents the browser from hanging. setTimeouts and setIntervals with
>>>>>>>>> an
>>>>>>>>> interval < 4ms are not clamped as aggressively as they were before.
>>>>>>>>> This
>>>>>>>>> improves short horizon performance, but websites abusing the API will
>>>>>>>>> still
>>>>>>>>> eventually have their set setTimeouts clamped
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Blink componentBlink
>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>>>>>>>>
>>>>>>>>> TAG review
>>>>>>>>>
>>>>>>>>> TAG review statusNot applicable
>>>>>>>>>
>>>>>>>>> Risks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>
>>>>>>>>> setTimeout is a well established and mature API. This change poses
>>>>>>>>> a risk of breaking websites and tests that rely on the current timing
>>>>>>>>> caused by clamping and the subtle task ordering that it entails. As an
>>>>>>>>> example, this change breaks assumptions about the ordering between
>>>>>>>>> setTimeout(0) and unrelated tasks in at least one case in Chrome
>>>>>>>>> tests (
>>>>>>>>> crbug.com/1302309). On the flip side, the implementation in
>>>>>>>>> Chrome is already non compliant (crbug.com/1108877). There's also
>>>>>>>>> a similar experiment on beta that is ongoing (crbug.com/1263190).
>>>>>>>>> Devs can use chrome://flags#unthrottled-nested-timeout to test their
>>>>>>>>> sites
>>>>>>>>> for compatibility issues.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Gecko: No signal
>>>>>>>>>
>>>>>>>>> WebKit: No signal
>>>>>>>>>
>>>>>>>>> Web developers: No signals
>>>>>>>>>
>>>>>>>>> Other signals:
>>>>>>>>>
>>>>>>>>> WebView Application Risks
>>>>>>>>>
>>>>>>>>> Does this intent deprecate or change behavior of existing APIs,
>>>>>>>>> such that it has potentially high risk for Android WebView-based
>>>>>>>>> applications?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Goals for experimentation
>>>>>>>>>
>>>>>>>>> Gain insight on potential compatibility issues and evaluate impact
>>>>>>>>> on guardian metrics (page load, latency).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ongoing technical constraints
>>>>>>>>>
>>>>>>>>> None
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Debuggability
>>>>>>>>>
>>>>>>>>> setTimeout() and setInterval() have an associated trace event in
>>>>>>>>> DevTools.
>>>>>>>>> https://developer.chrome.com/docs/devtools/evaluate-performance/performance-reference/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Will this feature be supported on all six Blink platforms
>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
>>>>>>>>>
>>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>>>>>>> ?No
>>>>>>>>>
>>>>>>>>> Flag nameunthrottled-nested-timeout
>>>>>>>>>
>>>>>>>>> Requires code in //chrome?False
>>>>>>>>>
>>>>>>>>> Tracking bughttps://crbug.com/1108877
>>>>>>>>>
>>>>>>>>> Estimated milestones
>>>>>>>>> OriginTrial desktop last 102
>>>>>>>>> OriginTrial desktop first 101
>>>>>>>>> DevTrial on desktop 101
>>>>>>>>> OriginTrial android last 102
>>>>>>>>> OriginTrial android first 101
>>>>>>>>> DevTrial on android 101
>>>>>>>>>
>>>>>>>>> Targeting Beta 50% for at least 8 weeks for more chance of teasing
>>>>>>>>> out breakage. I'll send a follow-up with what we learn prior to
>>>>>>>>> experimenting on Stable.
>>>>>>>>>
>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>> https://chromestatus.com/feature/5710690097561600
>>>>>>>>>
>>>>>>>>> Links to previous Intent discussionsReady for Trial:
>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/-TjeYs7shTQ/m/FhJq0mQyDAAJ
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This intent message was generated by Chrome Platform Status
>>>>>>>>> <https://chromestatus.com/>.
>>>>>>>>>
>>>>>>>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWAZZbGjJpLAAc6C3ohZ4ChJZioPt1vG3wqBPxE5ViLZA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWAZZbGjJpLAAc6C3ohZ4ChJZioPt1vG3wqBPxE5ViLZA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKZ%2BBNo1PXo_sw7wAnvv%2BviKFVg3dCa2fppH%3DzJ%3DV8GwJj3joQ%40mail.gmail.com.
