profiler
profiler copied to clipboard
firefox-devtools
Stacks containing ProcessNextEvent combines 2 or more stack parts that aren't related
See the profile https://perfht.ml/2vE9ASl
In this profile:
we see at the top some addon code and at the bottom some unrelated idle task.
cc fqueze
┆Issue is synchronized with this Jira Task
Why do you think this stack is not correct? It looks correct to me. syncLoadManifestFromFile spins a nested event loop by calling Services.tm.spinEventLoopUntil(() => success !== undefined), and then that nested event loop processes some idle tasks.
The stack is technically correct, but it's making it hard to compare stacks because as soon as something spins the event loop, any event can occur and be attached to the stack.
Julien and I discussed this as part of a larger discussion where I was talking about what makes comparing stacks in 2 profiles (to diff 2 profiles) difficult. I would like to make a simplified view where stacks contain only relevant frames, and I think ignoring all the frames before ProcessNextEvent would make sense.
I see. I'm wondering if a stack-oriented display is even the right tool for that particular job. If you want to compare the run times of runnables, it might be better to have a list of runnables with their run times. You can get something similar by doing "focus on function" on nsThread::ProcessNextEvent, but it's not perfect.
"Focus on function" is something we also looked at but it excludes the other samples. It would be nice to have the same transform as "Focus on function" for samples that contain the function, but without dropping the other samples.
Unpacking the discussion even more: I was saying that to be able to compare profiles from Talos, I would need to simplify the stacks so that stacks that are identical for my trained eyes but different for a computer become the same. And pushing that thought further, I was thinking the resulting transformed stacks would potentially also be nicer to look at in perf.html for normal profiles.
So if I understood properly Florian while discussing, what he wants is a transform to "detach" a part of a stack to make it top-level, ideally being able to detach the same function in the whole call tree. We could then merge the resulting call tree if the new top level functions have the same stacks. Is that so @fqueze ?
I think that would be useful, yes. Of course without having it it's hard to say how often I would actually use it.
ProcessNextEvent was one example of use case. InterpretGeneratorResume would be another one.
This issue is labelled as a bug, which from the discussion sounds like this is a feature request, as a new transform is being requested. I believe we should either close this bug, or rename the title to the desired transform, and write a detailed description of the transform operation.
ni? @julienw @fqueze
I agree it morphed from a bug to a feature request. There is something we should be able to do, knowing the internals of Firefox. Maybe some label at the right places would make it easier to implement a transform ?