Hi,
We will proceed with the Stable 1% experiment for this intervention.
Rationale:
-
- The MotionMark regression is well understood. I discussed
with +Camillo Bruni and we concluded that it isn't a blocker for
measuring
the impact of this intervention on Stable 1%. However, we will address
any
MotionMark regression before launching a change.
- Michal Mocny suggested worthwhile refinements. We will start by
measuring the impact of this intervention as-is on Stable 1%. If we
observe
good results, it will be a good justification for investing in a
"launchable" intervention, including integrating Michal Mocny's
suggestions.
Have a nice day,
François
On Tuesday, February 18, 2025 at 11:25:36 AM UTC-5 Li1 Chen wrote:
>
> https://issues.chromium.org/issues/337094888
> On Friday, February 14, 2025 at 4:26:47 PM UTC+8 uazo wrote:
>
>> > We tested an intervention on Canary/Dev/Beta that reduces the frame
>> rate by half (e.g., from 60fps to 30fps) after 4 consecutive frames without
>> pixel changes.
>>
>> would it be possible to study the changes you have made in the code? is
>> there an associated bugid? thank you.
>>
>> On Wednesday, February 12, 2025 at 6:41:56 PM UTC-2 Li1 Chen wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> We have tried Speedometer3 and MotionMark for this feature on pinpoint.
>>>
>>> Speedometer3:
>>>
>>> https://pinpoint-dot-chromeperf.appspot.com/job/11eca91ea10000
>>>
>>> https://pinpoint-dot-chromeperf.appspot.com/job/166ca91ea10000
>>>
>>> MotionMark:
>>>
>>> https://pinpoint-dot-chromeperf.appspot.com/job/11289a3ba10000
>>>
>>> https://pinpoint-dot-chromeperf.appspot.com/job/14289a3ba10000
>>>
>>>
>>>
>>> From the pinpoint data we can see that this feature does not affect the
>>> performance of Speedometer3. It only causes regression in the MotionMark
>>> subcase Design. The root cause is that the Design case uses rAF to
>>> calculate the frame length(
>>> https://github.com/WebKit/MotionMark/blob/baf37c1fcb690abbe048e249e248e7847bddd34f/MotionMark/tests/resources/main.js#L182),
>>>
>>> but there is no frame update. Since the frame rate is throttled after 4
>>> DidNotProduceFrame, the frame length is reduced to 33ms, which affects the
>>> complexity calculation in the case and causes regression. In MotionMark
>>> only Design case uses no-op frame to calculate frame length, which does not
>>> seem reasonable, so only this subcase is regressed.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Li
>>>
>>>
>>>
>>> On Monday, February 10, 2025 at 10:22:44 PM UTC+8 Camillo Bruni wrote:
>>>
>>>> +1 to double checking the benchmark
>>>> Most likely we're good as we should have at most a single idle rAF.
>>>>
>>>>
>>>> On Fri, 7 Feb 2025 at 20:13, Johnny Stenback <jste...@chromium.org>
>>>> wrote:
>>>>
>>>>> Hey Francois,
>>>>>
>>>>> This sounds promising. My one concern is what effect(s) this might
>>>>> have on our performance benchmarking work. +Camillo Bruni for his
>>>>> thoughts. We should at the very least make sure
>>>>> speedometer/motionmark/etc
>>>>> numbers are not negatively impacted by this change.
>>>>>
>>>>> Cheers,
>>>>> Johnny
>>>>>
>>>>> On Fri, Feb 7, 2025 at 10:03 AM Francois Pierre Doray <
>>>>> fdo...@chromium.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We tested an intervention on Canary/Dev/Beta that reduces the frame
>>>>>> rate by half (e.g., from 60fps to 30fps) after 4 consecutive frames
>>>>>> without
>>>>>> pixel changes. The frame rate returns to normal immediately upon pixel
>>>>>> changes or input events. For example:
>>>>>>
>>>>>> let last = performance.now();
>>>>>> let c = () => {
>>>>>> window.requestAnimationFrame(c);
>>>>>> let now = performance.now();
>>>>>> console.log(now - last);
>>>>>> last = now;
>>>>>> }
>>>>>> c();
>>>>>>
>>>>>> The c() function's invocation frequency halves after 4 calls due to
>>>>>> the lack of pixel updates. Note: As a result, a subsequent frame with
>>>>>> pixel
>>>>>> updates may be delayed by up to 1 frame (but frame rate returns to
>>>>>> normal
>>>>>> immediately after a frame with pixel updates).
>>>>>>
>>>>>> This intervention significantly improves LCP, INP and CPU usage on
>>>>>> Beta, confirming our prior observation that no-op frames often occupy
>>>>>> the
>>>>>> main thread during page load or input handling. To validate these
>>>>>> results,
>>>>>> we need a 1% stable experiment (user behavior differs between pre-stable
>>>>>> and stable channels). Before proceeding, we'd appreciate feedback on
>>>>>> potential issues this experiment might cause. We will determine our next
>>>>>> steps based on input from this discussion.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> François
>>>>>>
>>>>>> [cc: Chen, Li and Zheng, Hong from Intel who proposed and
>>>>>> implemented this intervention]
>>>>>>
>>>>>> --
>>>>>> 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 visit
>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6db8984-6c56-4e84-954b-7b0ffae8b461n%40chromium.org
>>>>>>
>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6db8984-6c56-4e84-954b-7b0ffae8b461n%40chromium.org?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> Camillo Bruni | Software Engineer, V8 | Google Germany GmbH |
>>>>> Erika-Mann
>>>> Str. 33, 80636 München
>>>>
>>>> Registergericht und -nummer: Hamburg, HRB 86891 | Sitz der
>>>> Gesellschaft: Hamburg | Geschäftsführer: Paul Manicle, Halimah DeLaine
>>>> Prado
>>>>
>>>> Diese E-Mail ist vertraulich. Falls Ssie diese fälschlicherweise
>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich
>>>> bitte
>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. This
>>>> e-mail is confidential. If you received this communication by mistake,
>>>> please don't forward it to anyone else, please erase all copies and
>>>> attachments, and please let me know that it has gone to the wrong person.
>>>>
>>>
--
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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a0a80f5c-3624-4be6-aa74-754833d117c1n%40chromium.org.
