LGTM2

On Wed, Mar 1, 2023 at 5:34 PM Chris Harrelson <chris...@chromium.org>
wrote:

> LGTM1 to ship. The API owners met today and it's fine to run a 50%
> experiment as part of the rollout. Thanks for the detailed work!
>
> On Tue, Feb 28, 2023 at 7:32 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
>
>> Thanks François for getting back to us, and I'm glad to hear we see
>> meaningful improvements with the 1 minute throttle.
>> From a web compat perspective, this *shouldn't* be highly observable, so
>> assuming you haven't gotten bug reports or saw an uptick in some other
>> metrics that can indicate this is causing an issue for backgrounded pages,
>> I think it's fine to experiment with this for a larger population set, to
>> get more meaningful results.
>>
>> In terms of the Blink process though, I'm not 100% sure what we want to
>> do here, given that this is an intent to ship. Maybe best to send an intent
>> to experiment with the exact experiment details you want to run. Would that
>> be too much overhead?
>>
>> On Mon, Feb 27, 2023 at 8:24 PM 'François Doray' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Hi blink-dev@!
>>>
>>> We experimented with the "Intensive Wake Up Throttling of Javascript
>>> Timers after 1 minute in Background" feature on Stable 1%. With 7 days of
>>> ramped up data, we observe small but statistically significant changes to
>>> CPU usage. In addition to these savings, this feature encourages Web
>>> developers to replace usage of Javascript timers with more efficient
>>> APIs
>>> <https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds>
>>> .
>>>
>>> Could we ramp up the experiment to 50% of stable to measure the savings
>>> with smaller confidence intervals? In particular, we don't expect to be
>>> able to capture battery life improvements with 1% of stable.
>>>
>>> Thanks,
>>>
>>> Francois
>>> On Monday, December 5, 2022 at 11:28:25 AM UTC-5 François Doray wrote:
>>>
>>>> Hi API owners,
>>>>
>>>> I agree that using a 1 minute grace period (instead of 10 seconds) is
>>>> less risky and will likely yield similar resource savings. We'll experiment
>>>> with this new grace period and keep you updated with the results.
>>>>
>>>> Side note: Chains of timers on background pages can usually be replaced
>>>> with more resource-efficient APIs, see
>>>> https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds.
>>>> We think it would be a good thing if, for example, Web content migrated
>>>> from polling a server to push Web Sockets in response to tighter
>>>> restrictions on timers.
>>>>
>>>> More details below.
>>>>
>>>> Have a nice day,
>>>>
>>>> François
>>>>
>>>> On Wed, Nov 23, 2022 at 12:03 PM Chris Harrelson <chri...@chromium.org>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The API owners discussed this intent today. In addition to the above
>>>>> questions, we achieved consensus that if you were content with 1 minute
>>>>> instead of 10 seconds, we'd be prepared to LGTM. For 10 seconds, we have
>>>>> additional concerns that would require more discussion and caveats. If 1
>>>>> minute achieves your goal of battery savings, could we go with that?
>>>>>
>>>> Yes we could.
>>>>
>>>>
>>>>>
>>>>> On Wed, Nov 16, 2022 at 5:15 PM Rick Byers <rby...@chromium.org>
>>>>> wrote:
>>>>>
>>>>>> Thinking some more about this, perhaps it really comes down to what
>>>>>> the nesting level >5 criteria means in practice? I guess metrics on how
>>>>>> common such tasks are won't be helpful because if they weren't common 
>>>>>> then
>>>>>> it wouldn't be attractive for power savings. But do you have anecdotal
>>>>>> experience suggesting that user-important events like Daniel and Philip 
>>>>>> are
>>>>>> worried about tend to be a lower nesting level, while things like 
>>>>>> analytics
>>>>>> and ads tracking tends to be higher nesting level? Any idea what data 
>>>>>> went
>>>>>> into the selection of "5" as the threshold?
>>>>>>
>>>>> For many years, the spec has said that the timeout of a timer with a
>>>> nesting level >5 is clamped to be >= 4ms.
>>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers
>>>> We used the same criteria to apply intensive throttling.
>>>>
>>>>>
>>>>>> It looks like there are other important heuristics too, like timers
>>>>>> started in network response handlers aren't subject to throttling. This 
>>>>>> is
>>>>>> clearly pretty nuanced, not something I'd really trust our judgement to 
>>>>>> be
>>>>>> able to accurately evaluate the risk of. Rather than try to speculate on
>>>>>> heuristic details here, perhaps it would be more productive to try to 
>>>>>> align
>>>>>> on the principals for how you're evaluating compat risk?
>>>>>>
>>>>>> In particular, no issue at 50% beta and 1% stable seems like a pretty
>>>>>> strong signal to me (especially relative to prior tab freezing efforts).
>>>>>> But how confident are you in bugs reaching you? Eg. if a tester bisects
>>>>>> based on a customer provided repo, is it likely to point to a CL you
>>>>>> landed? Or does this being under finch control mean that a bisect won't
>>>>>> work to identify the cause of a regression? I just searched for any bug
>>>>>> opened in the last 180 days which mentions setTimeout and setInterval in
>>>>>> the summary and didn't find anything relevant, so that's IMHO a 
>>>>>> significant
>>>>>> data point in your favor. Also the example you cite from the previous
>>>>>> change looks like it was quickly routed to you, so a good sign.
>>>>>>
>>>>> I admit that we don't have a perfect process to ensure that bugs are
>>>> routed to us. If someone experiences a problem, they could manually disable
>>>> features enabled via Finch (listed
>>>> at chrome://version/?show-variations-cmd). If they filed a bug with the
>>>> experiment name (QuickIntensiveWakeUpThrottlingAfterLoading), we would find
>>>> it. But I'm not convinced that most people would do this. We should
>>>> probably include clear debug steps in release notes?
>>>>
>>>>
>>>>>
>>>>>> Note I think we avoid 100% trials in beta because that leaves the
>>>>>> stable config unvalidated, so topping out at 50% on beta seems right to 
>>>>>> me.
>>>>>> But  what's the launch plan after that? Will you go straight to 100% 
>>>>>> stable
>>>>>> and consider backing back down if there are non-trivial reports of
>>>>>> breakage? Or do a gradual ramp?
>>>>>>
>>>>> We definitely want a 1% stable experiment to confirm that this change
>>>> has a positive impact. Ramping up to 50% stable gives us more confidence in
>>>> the results, but going straight to 100% stable to reduce variations between
>>>> Chrome clients also works.
>>>>
>>>>
>>>>>
>>>>>> Reading through the prior example you cited, I suspect the randomness
>>>>>> of finch trials could cause some frustration here - eg. some customers
>>>>>> complaining of breakage but devs being unable to reproduce it. What would
>>>>>> you think about ramping down the timer value predictably rather than
>>>>>> gradually ramping up the finch trial? I.e. drop 100% of stable users 
>>>>>> from 5
>>>>>> minutes to 2 minutes first? Perhaps a few weeks at 2 minutes, then 30
>>>>>> seconds without issue would be enough to reduce fear of going to 10 
>>>>>> seconds
>>>>>> while still giving predictability to developers trying to figure out 
>>>>>> what's
>>>>>> going on?
>>>>>>
>>>>> Gradually reducing the grace period for 100% of stable wouldn't let us
>>>> confirm that the intervention has a positive impact. What do you think of
>>>> experimenting with the target grace period for 1% stable to confirm impact,
>>>> and then launching by gradually reducing the grace period for 100% of
>>>> stable until we reach the target?
>>>>
>>>>
>>>>>
>>>>>> Rick
>>>>>>
>>>>>> On Wed, Nov 16, 2022 at 12:13 PM Daniel Bratell <brat...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi François,
>>>>>>>
>>>>>>> We [MikeT, Rick, Yoav, Chris and I] discussed this on the API Owners
>>>>>>> meeting and there were some things affecting user experience I was
>>>>>>> concerned about.
>>>>>>>
>>>>>>> Looking at the maximum perceived impact to the user, that would be
>>>>>>> that the user is putting a tab in the background, but expecting some 
>>>>>>> kind
>>>>>>> of event in a couple of seconds. If that event depends on the throttled
>>>>>>> timers, that event could, worst case, with this change be delayed from 
>>>>>>> 10
>>>>>>> seconds to 1 minute (or 10 seconds + 1 minute?). Before this change, 
>>>>>>> worst
>>>>>>> case would be that some event would be delayed from 5 minutes to 6 
>>>>>>> minutes.
>>>>>>>
>>>>>>> I consider, from a usage perspective, a delay from 5 to 6 minutes
>>>>>>> (worst case) acceptable if there are other benefits to the delay, but a
>>>>>>> change from 10 seconds to 1 minute (worst case) seems much more 
>>>>>>> impactful
>>>>>>> since it would be fivefold increase in waiting time.
>>>>>>>
>>>>>>> Considering that, have you investigated if there is some kind of
>>>>>>> middle ground where a smaller change would get more or less the same
>>>>>>> benefit to battery life? Or is there some other more advanced gradual
>>>>>>> throttling that could make the worst case less bad? Or do you have data
>>>>>>> that shows that my concern is irrelevant in some way?
>>>>>>>
>>>>>>> /Daniel
>>>>>>>
>>>>>>> On 2022-11-11 17:56, François Doray wrote:
>>>>>>>
>>>>>>> We are experimenting on 1% stable since the beginning of October
>>>>>>> 2022 (M106+). We are also experimenting on 50% of Canary/Dev/Beta since
>>>>>>> June 2022. Enabling on 100% of Canary/Dev/Beta for a few milestones 
>>>>>>> sgtm,
>>>>>>> if we think it will help identifying issues. So far, no bug reports have
>>>>>>> been routed to me.
>>>>>>>
>>>>>>> Note: Only timers with a "nesting level
>>>>>>> <https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timer-nesting-level>"
>>>>>>> greater than 5 are affected. A timer set from the visibilitychange event
>>>>>>> handler, for example, won't be affected.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 9, 2022 at 12:02 PM Philip Jägenstedt <
>>>>>>> foo...@chromium.org> wrote:
>>>>>>>
>>>>>>>> The potential compat risk of this seems significant, if it means
>>>>>>>> that pages can start misbehaving or breaking after 10 seconds in the
>>>>>>>> background, which seems common in workflows like logins or ecommerce, 
>>>>>>>> where
>>>>>>>> you might be flipping back and forth between tabs to find passwords,
>>>>>>>> confirm credit card transactions, etc.
>>>>>>>>
>>>>>>>> Have there been any bug reports from the beta experiment yet? To
>>>>>>>> increase confidence, can we run this experiment at 100% on beta, dev 
>>>>>>>> and
>>>>>>>> canary for a few milestones before trying it on stable? Are there any 
>>>>>>>> other
>>>>>>>> ways we can gain insight on the compat risk?
>>>>>>>>
>>>>>>>> On Tue, Nov 8, 2022 at 10:10 PM François Doray <fdo...@chromium.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Contact emails jiahe...@intel.com, fdo...@chromium.org
>>>>>>>>>
>>>>>>>>> Specification
>>>>>>>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>>>>>>>>
>>>>>>>>> Design docs
>>>>>>>>>
>>>>>>>>> https://docs.google.com/document/d/1WFyfKUUxqM7uKxKOGhLiOjyY6T7QRduVcuHN0f6vJkk/edit
>>>>>>>>>
>>>>>>>>> Summary
>>>>>>>>>
>>>>>>>>> Enter Intensive Wake Up Throttling after 10 seconds if the page is
>>>>>>>>> fully loaded when it becomes hidden. Currently, wake ups from JS 
>>>>>>>>> timers
>>>>>>>>> with a nesting level >= 5 are throttled to 1 per minute after the 
>>>>>>>>> page has
>>>>>>>>> spent 5 minutes in the background [1], which is very conservative and 
>>>>>>>>> was
>>>>>>>>> chosen to allow a launch of Intensive Wake Up Throttling with minimal
>>>>>>>>> regression risk. We're now planning to reduce this timeout to 10 
>>>>>>>>> seconds if
>>>>>>>>> the page is fully loaded when hidden. [1]
>>>>>>>>> https://chromestatus.com/feature/4718288976216064
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Blink component Blink>Scheduling
>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling>
>>>>>>>>>
>>>>>>>>> TAG review status Not applicable
>>>>>>>>>
>>>>>>>>> Risks
>>>>>>>>>
>>>>>>>>> Interoperability and Compatibility
>>>>>>>>> *Gecko*: No signal
>>>>>>>>>
>>>>>>>>> *WebKit*: No signal
>>>>>>>>>
>>>>>>>>> *Web developers*: No signals
>>>>>>>>>
>>>>>>>>> *Other signals*: The more conservative version of Intensive Wake
>>>>>>>>> Up Throttling shipped smoothly to 100% Stable more than 1 year ago. A 
>>>>>>>>> few
>>>>>>>>> bugs were filed, but in all cases we've been able to propose 
>>>>>>>>> workarounds
>>>>>>>>> which made apps more efficient (example
>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1186569#c16>
>>>>>>>>> ).
>>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, this feature will not ship on desktop platforms.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Debuggability
>>>>>>>>>
>>>>>>>>> This is not a new Web Platform feature.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Will this feature be supported on all six Blink platforms
>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? No
>>>>>>>>>
>>>>>>>>> This feature will only ship on desktop platforms. On Android, the
>>>>>>>>> system severely limits resource consumption in background renderers, 
>>>>>>>>> which
>>>>>>>>> makes this feature unnecessary.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>> ? Yes
>>>>>>>>>
>>>>>>>>> Flag name quick-intensive-throttling-after-loading
>>>>>>>>>
>>>>>>>>> Requires code in //chrome? False
>>>>>>>>>
>>>>>>>>> Tracking bug
>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1324656
>>>>>>>>>
>>>>>>>>> Estimated milestones
>>>>>>>>> DevTrial on desktop
>>>>>>>>>
>>>>>>>>> Enabled by default on desktop 104
>>>>>>>>>
>>>>>>>>> 109
>>>>>>>>> Anticipated spec changes
>>>>>>>>>
>>>>>>>>> Open questions about a feature may be a source of future web
>>>>>>>>> compat or interop issues. Please list open issues (e.g. links to known
>>>>>>>>> github issues in the project for the feature specification) whose
>>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to 
>>>>>>>>> naming
>>>>>>>>> or structure of the API in a non-backward-compatible way).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>> https://chromestatus.com/feature/5580139453743104
>>>>>>>>>
>>>>>>>>> *Additional context*
>>>>>>>>>
>>>>>>>>> The 1% stable experiment shows that this feature reduces Chrome's
>>>>>>>>> CPU usage and extends battery life, as desired. We plan to enable it 
>>>>>>>>> by
>>>>>>>>> default in M109.
>>>>>>>>>
>>>>>>>>> The 1% stable experiment is still ramping up, so we would like to
>>>>>>>>> keep experimenting in M108, to get small confidence intervals for all 
>>>>>>>>> our
>>>>>>>>> metrics on all desktop platforms.
>>>>>>>>> --
>>>>>>>>> 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 blink-dev+...@chromium.org.
>>>>>>>>> To view this discussion on the web visit
>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5EGWuOZgo1k5XExKpnjsRM9nacEeFMyiXkEOwW%3DkOqRUQ%40mail.gmail.com
>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5EGWuOZgo1k5XExKpnjsRM9nacEeFMyiXkEOwW%3DkOqRUQ%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 blink-dev+...@chromium.org.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5Fy3FRsxTwde26%3DincDr7PR%2Bz4VKowfikMkPgSxxLhScA%40mail.gmail.com
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5Fy3FRsxTwde26%3DincDr7PR%2Bz4VKowfikMkPgSxxLhScA%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 blink-dev+...@chromium.org.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e54c5cf-72be-500f-c3d3-a1cf00514447%40gmail.com
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e54c5cf-72be-500f-c3d3-a1cf00514447%40gmail.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 blink-dev+...@chromium.org.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-Kvf6341Fbyi1ggxrKDTPfrSXcfVP_9FG%2Bmk%2BKbO2ZjA%40mail.gmail.com
>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-Kvf6341Fbyi1ggxrKDTPfrSXcfVP_9FG%2Bmk%2BKbO2ZjA%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 blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/514eef7d-5c70-4da1-a8fb-d892f3b5e1aan%40chromium.org
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/514eef7d-5c70-4da1-a8fb-d892f3b5e1aan%40chromium.org?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 blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUhYHKBk9nMJs7dCORDP_NZPEabrnxUe42emDJhrmkixA%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUhYHKBk9nMJs7dCORDP_NZPEabrnxUe42emDJhrmkixA%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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXwNs7YUS4gYDYh7-KijKxiHdQVaiDL5h8u9exvPSgB7Q%40mail.gmail.com.

Reply via email to