Closed Bug 1132525 Opened 9 years ago Closed 7 years ago

Profile multiple threads for workers/e10s/b2g

Categories

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

defect

Tracking

(e10s-)

RESOLVED WONTFIX
Tracking Status
e10s - ---

People

(Reporter: jsantell, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: DevAdvocacy, Whiteboard: [devtools-platform][gaming-tools][DevRel:P2])

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++)
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)
Flags: needinfo?(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.
Flags: needinfo?(jsantell) → needinfo?(bgirard)
No longer blocks: perf-tool-v2
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.
Flags: needinfo?(bgirard)
Blocks: perf-tool-v2
No longer blocks: enable-perf-tool
Not specifically blocking v2.
No longer blocks: perf-tool-v2
Need to evaluate for 40.1, as we need to make sure we're not missing anything in our profiles.
Summary: Profile multiple threads in e10s/b2g in new perf++ → Profile multiple threads for workers/e10s/b2g
From bug 1153443, should also profile worker threads, and when platform data is on, gecko threads.
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.
Keywords: DevAdvocacy
Whiteboard: [devtools-platform]
Blocks: perf-gaming
Priority: -- → P1
Whiteboard: [devtools-platform] → [devtools-platform][gaming-tools]
Eddy, do worker threads have a consistent "thread name" we can target with the SPS profiler?
Flags: needinfo?(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.
Flags: needinfo?(ejpbruel)
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
ni? for the last comment
Flags: needinfo?(ejpbruel)
Ping Eddy
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.
Agreed on the visual layout, Nick; the nsIProfiler currently handles multiple threads at once, for well-known threads anyway.
Depends on: 1240835
Depends on: 1240836
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!
Flags: needinfo?(ejpbruel)
OS: Mac OS X → All
Hardware: x86 → All
Version: 37 Branch → unspecified
Priority: P1 → P2
Whiteboard: [devtools-platform][gaming-tools] → [devtools-platform][gaming-tools][DevRel:P2]
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.