1545001 - ThreadEventQueue::GetEvent should not use category IDLE when invoked for "local execution mode"

Status: NEW

(Core :: Gecko Profiler, enhancement, P3)

Description

[Markus Stange [:mstange]]

Profile: https://perfht.ml/2VQdLDg

This profile makes it look like the main thread was idle for about 3 seconds. But in reality, the main thread was blocked, waiting for something from local storage. No user input was processed during that time.

ThreadEventQueue::GetEvent currently pushes a profiling label with the IDLE category while it waits for events. This is sensible when we're waiting for events from the main event queue. But GetEvent can also be invoked for "local execution modes" where it only processes some events but not all. In that case, the browser is blocked and should not be considered idle. The call site to GetEvents for that case is nsThread::ProcessNextEvent, inside an if (mIsInLocalExecutionMode).

Maybe we can pass a flag down to GetEvents for that case, and make it use a different profiling category?

Comment 1

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Or could we have different labels around each call to GetEvent() instead? I only see 3 of them:
https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla22SynchronizedEventQueue8GetEventEbPNS_18EventQueuePriorityE&redirect=false

Comment 2

[Markus Stange [:mstange]]

Yes, that should work! It would also mark stacks inside EventQueue::GetEvent (i.e. the code that actually pops an object from the queue) as idle, but I think that's ok, since that code should run quickly enough that it's rarely sampled.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bot thinks this bug is a task, but please change it back in case of error.