RE: [EXTERNAL] Re: Reasoning for running Performance_Manager in the UI thread
Javier Flores Assad
Thanks Joe.
Is there a Slack channel I can join?
Also, how can I learn more about the backlog and plans for PM, I might be able to help.
From: Joe Mason <joenot...@google.com>
Sent: Tuesday, December 5, 2023 12:02 PM
To: Javier Flores Assad <flo...@microsoft.com>
Cc: Bruce Dawson <bruce...@chromium.org>; Francois Pierre Doray <fdo...@chromium.org>; scheduler-dev <schedu...@chromium.org>; Patrick Langlois Monette <pmon...@google.com>
Subject: [EXTERNAL] Re: Reasoning for running Performance_Manager in the UI thread
|
You don't often get email from joenot...@google.com. Learn why this is important |
Oops! I re-added all the CC's on the original email, and forgot about the From address! Sorry about that, Javier.
See my reply below.
On Tue, Dec 5, 2023 at 12:41 PM Joe Mason <joenot...@google.com> wrote:
+scheduler-dev for transparency
The main reason is that the constant need to post back and forth from the PM sequence is a drain on developer productivity. We've found that we spend a lot more time dealing with boilerplate than we expected to make sure things run on the right sequence.
It can also cause more work overall as information that could be simply looked up on the main thread needs the overhead of PostTaskAndReply.
Balancing this, as you say, is that some of the logic can be intensive. After a few years of experience with PM we think the less-intensive workloads dominate, meaning that the overhead of a dedicated PM sequence isn't very useful. (Both cognitive overhead for developers and scheduling overhead of extra tasks.) The plan is to switch to the same strategy as Chrome in general - identify specific workloads that are too heavy to run on the UI thread and run those specifically on thread pool workers.
On Tue, Dec 5, 2023 at 11:53 AM Patrick Langlois Monette <pmon...@google.com> wrote:
---------- Forwarded message ---------
From: Javier Flores Assad <flo...@microsoft.com>
Date: Mon, Dec 4, 2023, 1:35 p.m.
Subject: Reasoning for running Performance_Manager in the UI thread
To: bruce...@chromium.org <bruce...@chromium.org>, fdo...@chromium.org <fdo...@chromium.org>, pmon...@chromium.org <pmon...@chromium.org>
Hi everyone.
While integrating code from chromium main into Edge, I have seen more code being done towards advancing this effort:
I’m unclear as to why we want to move more workloads into the UI thread instead of keeping them off-thread (given they already work that way).
Some of the PM logic can get intensive when there are a lot of pages (tabs) with a lot of frames.
Are we sure moving work unrelated to update the UI into the UI thread is a the right direction?
Let me know if there is a better way for us to chat about this, I would love to learn more about the motivation and if we can help somehow.
Thank you!
-Javier
Joe Laughlin
@Etienne Bergeron we’re concerned about additional activity on the UI thread. Have we considered other options here? Is there a slack channel for this or a backlog and/or plans for PM we can cooperate on?