Looking at the profiler overhead (in microseconds, "ns" is wrong, seehttps://github.com/firefox-devtools/profiler/issues/2603 ), 69% of the time is spent in the locked sampling loop, which takes ~1.8ms on average, so it's no surprise that `profiler_get_backtrace()` may take a while to get its turn! Regarding the time spent in profiler locks, I think bug 1651259 is relevant (trying not to use locks in `profiler_get_backtrace()` if possible). We also have bug 1578792 to try and remove allocations, and at the moment I'm implementing bug 1658232, which removes at least one (small) allocation in all cases, and will get rid of most allocations when using the new markers API. Are there any other sources of overhead these bugs would not cover? In the meantime, if you want to have such high-frequency markers with stacks, you could try the "No Periodic Sampling" option, or at least reduce the sampling frequency.
Bug 1658045 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Looking at the profiler overhead (in microseconds, "ns" is wrong, see https://github.com/firefox-devtools/profiler/issues/2603 ), 69% of the time is spent in the locked sampling loop, which takes ~1.8ms on average, so it's no surprise that `profiler_get_backtrace()` may take a while to get its turn! Regarding the time spent in profiler locks, I think bug 1651259 is relevant (trying not to use locks in `profiler_get_backtrace()` if possible). We also have bug 1578792 to try and remove allocations, and at the moment I'm implementing bug 1658232, which removes at least one (small) allocation in all cases, and will get rid of most allocations when using the new markers API. Are there any other sources of overhead these bugs would not cover? In the meantime, if you want to have such high-frequency markers with stacks, you could try the "No Periodic Sampling" option, or at least reduce the sampling frequency.