Right now a JSON profile is sent over the RDP. It seems that array buffers are now supports for some instances. We should see if we can make it faster when running locally by getting the gzipped version sent over RDP, rather than the full Profile.

The two browser calls are:

• Services.profiler.getProfileDataAsGzippedArrayBuffer
• Services.profiler.getProfileDataAsync

(In reply to Greg Tatum [:gregtatum] from comment #0)

It seems that array buffers are now supports for some instances.

Nicolas, do you know more details about this? Can array buffers be sent over the devtools protocol these days?

(In reply to Markus Stange [:mstange] from comment #1)

(In reply to Greg Tatum [:gregtatum] from comment #0)

It seems that array buffers are now supports for some instances.

Nicolas, do you know more details about this? Can array buffers be sent over the devtools protocol these days?

So I don't know much about this, but I don't think we can send ArrayBuffers through RDP.
Looking at the code, it seems that we're interested in this function: https://searchfox.org/mozilla-central/rev/5227b2bd674d49c0eba365a709d3fb341534f361/devtools/shared/performance-new/gecko-profiler-interface.js#147-186

It's in devtools/shared which means it can be accessed from the DevTools client and the DevTools server.
So what could be done is to detect when we're not debugging a remote server, and in such case, directly call getProfileAndStopProfiler from the client (from here I guess https://searchfox.org/mozilla-central/rev/5227b2bd674d49c0eba365a709d3fb341534f361/devtools/client/performance-new/store/actions.js#211)

That's something we thought at some point for screenshots, where a long time is spent stringifying data so we can send them through RDP, although we could directly access them when we're not debugging remotely.

Thanks! It's somewhat unsatisfying to leave remote targets on the slow path, though. And it sounds like the ability to remotely transmit array buffers efficiently would be useful in other places, too. I can file a bug about adding this capability; do you know who'd be the right person to assess the feasibility of this?

(In reply to Markus Stange [:mstange] from comment #3)

Thanks! It's somewhat unsatisfying to leave remote targets on the slow path, though. And it sounds like the ability to remotely transmit array buffers efficiently would be useful in other places, too. I can file a bug about adding this capability; do you know who'd be the right person to assess the feasibility of this?

ochameau and jdescottes should know more than me about the different DevTools transport layers

Yes, there is a binary escape path in RDP.
Unfortunately, it isn't super documented, nor used.

There is this one usage you can take as example, the memory profile generated by the memory panel.

Server side code:
https://searchfox.org/mozilla-central/rev/c0fc8c4852e927b0ae75d893d35772b8c60ee06b/devtools/server/actors/heap-snapshot-file.js#57-82
On this side, the key here is to use this.conn.startBulkSend and bulk.copyFrom.

Client side code:
https://searchfox.org/mozilla-central/rev/c0fc8c4852e927b0ae75d893d35772b8c60ee06b/devtools/client/fronts/memory.js#82-113
Note that this client code should be using DevToolsClient.startBulkRequest. (no idea why it isn't)
On this side, it is about using client.startBulkRequest and const { copyTo } = await request;

This is completely bypassing protocol.js, so there is nothing to declare in your spec (i.e. devtools/shared/spec).

Let me know if you need any more help with this.

Thanks a lot for these pointers! I will give this a try, once I get around to it.

Hah, funnily enough, the profiler is the primary use case in the description of bug 797639, which added the bulk writing capabilities 9 years ago. "Performance profiling" is also mentioned in a section about bulk data in the Remote Debugging Protocol documentation.

Morphing this bug to switch to the bulk sending APIs from comment 5. At the moment, we parse the profile into JSON on the Android device by using the API getProfileDataAsync here, and then we send the JS object across the pipe.