1832025 - Profiler labels show up in the profiles which aren't created using Firefox profiler

Status: RESOLVED DUPLICATE of bug 1853720

(Core :: Gecko Profiler, enhancement, P2)

Description

[Olli Pettay [:smaug][[e-mail]]]

https://share.firefox.dev/3VHXPTl

Comment 1

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Unfortunately we have to run the AutoProfilerLabel constructor even when the profiler is not running. Otherwise we will lose some of the label frames that are executed while the profiler is inactive.

But I hope we can find some things that we can optimize, so it will be quite negligible to run this code.
I see two expensive calls. mozilla::profiler::ThreadRegistration::GetTLS and mozilla::detail::AtomicBase::operator= inside js::ProfilingStackFrame::initLabelFrame.

It's very weird that mozilla::profiler::ThreadRegistration::GetTLS call is the most expensive one. The content of this call is fairly small: https://searchfox.org/mozilla-central/rev/373d05f4eabdb90a6480d5d36d983b8bff36c9d8/tools/profiler/public/ProfilerThreadRegistration.h#355-356
The first one initializes the ThreadLocal variable in the first run and then it will return early on the consecutive calls. The second line is just returning the pointer. I'm not sure if there is room for optimizations there, but I will continue to look at it.

Comment 2

[Julien Wajsberg [:julienw]]

For some more context, searching from "AutoProfilerLabel" on the full tree shows 1850 samples on 165622 samples for the full tree. That's 1.11%, so it's small but it's not insignificant.
It would be good to understand why GetTLS Is slow on this profile.
I also see some atomics showing up in this profile.
Here is possibly a better view over this overhead: https://share.firefox.dev/41kuWNW

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Anything >1% is a lot to my eyes ;)

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

I think this is basically a dup of bug 1853720