1371003 - Provide an API for a remote nsIProfiler

Status: NEW

(WebExtensions :: Developer Tools, enhancement, P3)

Description

[Alex Thayer [:alexical] (she/her)]

In order to support profiling Fennec with the Gecko Profiler WebExtension, we'll need to expose an API like the geckoProfiler API specificially for a remote tab. If we can get 1304378 landed then we can just have devtools give us a profiler proxy for a given remote tab.

Comment 1

[Markus Stange [:mstange]]

We may not need this API if we expand the new minimal devtools panel from bug 1408124 to support remote profiling.

Comment 2

[Makoto Kato [:m_kato]]

(In reply to Markus Stange [:mstange] from comment #1)
> We may not need this API if we expand the new minimal devtools panel from
> bug 1408124 to support remote profiling.

startProfile method requires additional options for remote such as is_remote, host and port.

Comment 3

[Markus Stange [:mstange]]

Are you referring to the WebExtension API (geckoProfiler.start()) or to nsIProfiler.StartProfiler? Or maybe to something else?

If only allow remote profiling for the new devtools panel and don't need to worry about making it work for the Gecko-Profiler add-on, then I don't think either of them need these additional options: The devtools panel won't be using the WebExtensions API, and it would be using the devtools actor to transfer the profile JSON. nsIProfiler.StartProfiler would only be called on the Android side.

Comment 4

[Makoto Kato [:m_kato]]

(In reply to Markus Stange [:mstange] from comment #3)
> Are you referring to the WebExtension API (geckoProfiler.start()) or to
> nsIProfiler.StartProfiler? Or maybe to something else?

Web Extension API.
 
> If only allow remote profiling for the new devtools panel and don't need to
> worry about making it work for the Gecko-Profiler add-on, then I don't think
> either of them need these additional options: The devtools panel won't be
> using the WebExtensions API, and it would be using the devtools actor to
> transfer the profile JSON. nsIProfiler.StartProfiler would only be called on
> the Android side.

As performance panel (devtools/performance-new/components/Perf.js), it doesn't use Web Extension API.  But Gecko Profiler uses Web Extension API, then it calls Services.profiler.StartProfiler directly.  So Gecko profiler supports remote profiling, an option (for host and port?) will be required.

Comment 5

[Makoto Kato [:m_kato]]

New performance panel cannot customize options for profiling, so I will file a issue as bug 1444796.

And if gecko profiler cannot be used without performance panel, new API and options won't required.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Makoto Kato [:m_kato] from comment #5)
> And if gecko profiler cannot be used without performance panel, new API and
> options won't required.

This is concerning... previous investigation has shown that having devtools open at all (even on a blank panel) causes desktop page loads to increase up to 50% in time.  This throws any profile collected during the load badly off.  

Where is the performance panel running?  Does this cause the sort of impact as I've seen with devtools?  Thanks

Comment 7

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Randell Jesup [:jesup] from comment #6)
> (In reply to Makoto Kato [:m_kato] from comment #5)
> > And if gecko profiler cannot be used without performance panel, new API and
> > options won't required.
> 
> This is concerning... previous investigation has shown that having devtools
> open at all (even on a blank panel) causes desktop page loads to increase up
> to 50% in time.  This throws any profile collected during the load badly
> off.  
> 
> Where is the performance panel running?  Does this cause the sort of impact
> as I've seen with devtools?  Thanks

The slowdown you are seeing seems like something we should explore separately from this bug. There are many possible reasons for the perf impact you describe, so it's likely best to investigate and triage the issues first.

In the current world, the toolbox starts listening to many things on open, so undoubtedly that slows things down. It also runs in the parent process, so that will also affect general browser perf. Perhaps we'll want something different when starting from the profiler tab, or maybe we can resolve these underlying issues in a different way that improves things for all DevTools users.

Could you open a new bug with a profile of what you're seeing?

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #7)
> (In reply to Randell Jesup [:jesup] from comment #6)
> > (In reply to Makoto Kato [:m_kato] from comment #5)
> > > And if gecko profiler cannot be used without performance panel, new API and
> > > options won't required.
> > 
> > This is concerning... previous investigation has shown that having devtools
> > open at all (even on a blank panel) causes desktop page loads to increase up
> > to 50% in time.  This throws any profile collected during the load badly
> > off.  
> > 
> > Where is the performance panel running?  Does this cause the sort of impact
> > as I've seen with devtools?  Thanks
> 
> The slowdown you are seeing seems like something we should explore
> separately from this bug. There are many possible reasons for the perf
> impact you describe, so it's likely best to investigate and triage the
> issues first.

I had profiles showing the slowdown, and it's easy to repro.  It's spending a lot of time in JS code on MainThread of the master process, processing all the incoming data - even if I select a panel that's displaying nothing.  This blocks mainthread for significant periods of time.  I discussed this with a number of people at AllHands; the main options would be (maybe, likely very hard) moving most of the devtools code to workers, or (as Chrome apparently does - I haven't verified) run the DevTools code in a separate process (renderer for Chrome).  Chrome doesn't show this slowdown.

> In the current world, the toolbox starts listening to many things on open,
> so undoubtedly that slows things down. It also runs in the parent process,
> so that will also affect general browser perf.

This is exactly what the profiles show.

> Perhaps we'll want something
> different when starting from the profiler tab, or maybe we can resolve these
> underlying issues in a different way that improves things for all DevTools
> users.

So I'll note that Chrome Devtools seems to suspend all rendering from DevTools (and maybe processing) while capturing a Profile; it just shows a "stop" button.  We could do something similar and "neuter" devtools while taking a profile -- however, normal devtools operation would still seriously affect timings (i.e. don't try to figure out why your page does something slowly by doing it with devtools open -- which most developers would assume is valid. (I.e. to look at the Network panel and see what it's doing during page load, etc).

> Could you open a new bug with a profile of what you're seeing?

Sure.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

Bug 1459720 is about avoiding the devtools actor impact when remote profiling.

Comment 10

[Makoto Kato [:m_kato]]

Actually, we don't have any way to stop profiler with MOZ_PROFILER_STARTUP. If using Fennec, Fennec has Quit menu when using MOZ_PROFILER_SHUTDOWN. But GeckoView example doesn't have it.

We might be necessary for any intents to start and stop profiler on GeckoView example to analyze GeckoView performance issue.