Capture performance tracing via Electron contentTracing API

[timfish]

Electron includes a contentTracing API which allows you to capture traces in the Chromium json trace event format.

Could this be parsed and converted to format suitable for submitting to Sentry?

[JonasBa]

@timfish we are not far from being able to visualize that format on the sentry dashboard, there are a couple of important things to note:

• the doc you shared is (mostly) out of date. I tried using it when I was trying to parse the format, and ended up just reading the v8 source.
• I cannot recall where I read this, but I remember reading that historically that format has changed frequently and that has made it hard to consistently keep up to it's latest spec. In other words, breaking changes to v8's API do not seem to be a major concern
• IIrc that format was quite heavyweight (the equivalent of what is collected through devtools easily exceeds tens of megabytes which make it a poor fit for network transfer). Would be great if we could have a few example profiles collected from a few representative use-cases to see if this would be feasible.
• It is not mentioned anywhere in the electron docs, but I assume that the startProfiling/stopProfiling are electron bindings to the v8 cpu and memory profiler? If not, are you aware of any performance overhead benchmarks that we could take a look at?

[timfish]

IIrc that format was quite heavyweight

Indeed it can be, although it looks like you have full control of the categories that are captured so it might be possible to keep it slimmed down.

Would be great if we could have a few example profiles

I'll see what I can do!

but I assume that the startProfiling/stopProfiling are electron bindings to the v8 cpu and memory profiler?

Yes, as far as I understand it, it hits up the same code as Chrome dev tools

[JonasBa]

Indeed it can be, although it looks like you have full control of the categories that are captured so it might be possible to keep it slimmed down.

That is great, we can hopefully trim it down to the bare minimum.

Yes, as far as I understand it, it hits up the same code as Chrome dev tools
From my investigations, the direct output of the CPU profiler (when interfacing with node bindings) is not a chrometrace like format, it is instead more like a call graph (see GetTopDownRoot method)

I'm actually wondering if we could avoid using the electron API and just import our own profiling sdk for node. I know very little about Electron, but the idea that profiling interface is re-exposed through Electron makes me think that our own bindings would not work.

[timfish]

just import our own profiling sdk for node

In Electron you have the main root node process that is mainly used for opening and taking care of windows and orchestrating IPC. Each window (a "renderer") is essentially a Chromium tab and with the default configuration there is no node.js available in these. They highly discourage enabling node.js in the browser windows because of the many security implications when mixed with remote content!

There are ways to expose node.js functionality into the browser windows but this is via an isolated context (I think using the same underlying tech as Chromium extensions). However this isolated context probably makes it useless for things like tracing where I'm guessing globals and things get patched, modified etc.