1330576 - Profiling JS has higher overhead than non-JS

Status: NEW

(Core :: Gecko Profiler, defect, P3)

Description

[Markus Stange [:mstange]]

This results in profiles that can be misleading because they show a higher percentage of samples in JS execution.

Slow JS stackwalking (e.g. due to storing long strings in the profiler buffer) can also lead to higher starvation of the thread while more JS is on the stack.

Comment 1

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

I have the (possibly wrong) gut feeling that JS profiling can never be as light as native profiling, so I'm not too sure that this bug title can ever be fixed. 🤔
But in any case, any possible improvement is of course welcome and should be investigated. Should this bug be changed to a "task", maybe meta, titled something like "Reduce overhead of JS profiling".

Slow JS stackwalking (e.g. due to storing long strings in the profiler buffer)...

I don't understand the link from long strings to slower stack-walking. Of course copying more bytes takes more time, but I would guess it's quite negligible compared to everything else that happens during stack-walking, and we don't control how long these strings are anyway so we can't just make them smaller (right?).

It would be good if we could really profile the profiler (e.g., from Linux perf, or maybe more intrusive tracing profiling?), and see where time is spent during native/JS profiling, including the extra time spent outside of stack-walking itself, when the JS engine stores extra information for the benefit of the profiler.