1132525 - Profile multiple threads for workers/e10s/b2g

Status: RESOLVED WONTFIX

(DevTools :: Performance Tools (Profiler/Timeline), defect, P2)

Description

[Jordan Santell [:jsantell] [@jsantell]]

Right now, we only profile and use the first thread in a profile (`profile.threads[0]`) in much of the front and back of the Profiler. This may be from nsIProfilerModule.getProfileData(), or something filtered out in the front (which does happen in perf++)

Comment 1

[Liz Henry (:lizzard) (relman/hg->git project)]

Jordan, so if I'm understanding this correctly, this means web developers using the profiler (and timeline) may not see profile information on the tab they're looking at if they have multiple tabs open? How much impact do you think this would have for users on Aurora?  (Once e10s is enabled on Aurora)

Comment 2

[Jordan Santell [:jsantell] [@jsantell]]

Liz, forwarding this ping to BenWa, who knows more about the nsIProfiler -- I'm not sure what we're missing on e10s/b2g. Updating the front end (new performance tool, to be in nightly for Fx39) to merge threads is pretty straight forward, though.

Comment 3

[Benoit Girard (:BenWa)]

The profiler backend can already profile multiple threads including WebWorkers. However the devtools frontend doesn't expose this option AFAIK.

The profiler also tried to filter out activity that is occurring in background tabs. If you don't want that then the platform profiler is probably what you're looking for.

Comment 4

[Victor Porof [:vporof][:vp]]

Not specifically blocking v2.

Comment 5

[Jordan Santell [:jsantell] [@jsantell]]

Need to evaluate for 40.1, as we need to make sure we're not missing anything in our profiles.

Comment 7

[Jordan Santell [:jsantell] [@jsantell]]

From bug 1153443, should also profile worker threads, and when platform data is on, gecko threads.

Comment 8

[Dan Callahan [:callahad]]

Adding the DevAdvocacy keyword. Being able to profile a worker (even through manual calls to console.profile/profileEnd) would be invaluable. I can't otherwise measure or improve the performance of code inside my workers, which tend to be the most expensive computations on a page.

I most recently ran into this while putting together the DevEdition 40 perf tools video.

Comment 10

[Jordan Santell [:jsantell] [@jsantell]]

Eddy, do worker threads have a consistent "thread name" we can target with the SPS profiler?

Comment 11

[Eddy Bruel [:ejpbruel]]

(In reply to Jordan Santell [:jsantell] [@jsantell] (Please needinfo) from comment #10)
> Eddy, do worker threads have a consistent "thread name" we can target with
> the SPS profiler?

Each WorkerPrivate has a mPRThread member variable, which is an instance of PRThread, and represents the thread for that worker. This thread does not change during the lifetime of the WorkerPrivate, and can be said to be consistent in that sense.

However, mPRThread is currently a private member, so you cannot make direct use of it. Moreover, although PRThread does seems to have an interface to get/set the thread name, this looks to me like its intended for debugging purposes only.

I'm not sure what functionality you need exactly for the SPS profiler, but if you let me know, I can look into it, and make sure you get what you need.

Comment 12

[Jordan Santell [:jsantell] [@jsantell]]

The SPS profiler uses thread names to select[0], and the threads profiled in the gecko profiler use some well known names (like "Compositor" for the compositing thread, etc), and I couldn't find a way to search or target worker threads (as I couldn't find their name) -- any ideas?

Another limitation is I think we'll need to know the names of the threads before we start profiling, so in the case where workers are initialized after the recording starts, we'd have to be aware that there even is a new thread, and possibly stop and restart the profiler with that thread in mind. Not sure how we can handle that with current functionality.

[0] https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler#Profiling_Threads

Comment 13

[Jordan Santell [:jsantell] [@jsantell]]

ni? for the last comment

Comment 14

[Jordan Santell [:jsantell] [@jsantell]]

Ping Eddy

Comment 15

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

So the one other thought I have on this is that I often would want to profile the main thread and worker thread *together* rather than have a new toolbox for the worker thread like our other worker-scoped tools do. Performance is holistic and I want to view it as such. I was to see, "oh the main thread is largely idle after point X because I am farming out to a worker" and then be able to look at the performance profile of the worker immediately without opening a new and specially scoped toolbox.

Something to keep in mind when designing and architecting how we want to do this.

Comment 16

[Jordan Santell [:jsantell] [@jsantell]]

Agreed on the visual layout, Nick; the nsIProfiler currently handles multiple threads at once, for well-known threads anyway.

Comment 17

[Jordan Santell [:jsantell] [@jsantell]]

According to Eddy and BenWa, we should be able to add "DOM" as a named thread to the nsIProfiler, which will observe all current, and future, web workers (who have the name "DOM Worker *"). Seems too good to be true!

Comment 18

[Greg Tatum [:gregtatum] (REO Fx132)]

perf.html supports viewing multiple threads. I'm closing this bug, but we can re-open new ones for selecting worker threads correctly in the new recording panel, which is still needed.