1841030 - mozilla::MarkerThreadId::CurrentThread is slow

Status: RESOLVED FIXED

(Core :: Gecko Profiler, defect, P2)

Description

[Julien Wajsberg [:julienw]]

I noticed a large profiler overhead in https://share.firefox.dev/3PRC02T while profiling a speedometer 3 workload.

From this profile, mozilla::MarkerThreadId::CurrentThread seems to be very visible especially (in addition to the usual suspects around capturing a backtrace in a buffer).

According to padenot, we should look at using pthread_self instead of gettid (that does a syscall):

syscall(SYS_gettid) -- took: 513.187 ms [0.513187us per iteration]
pthread_self -- took: 0 ms [0us per iteration]
11044057845185138688
getttid -- took: 504.234 ms [0.504234us per iteration]
11044058531219138688

Comment 1

[Julien Wajsberg [:julienw]]

See also bug 1721569 which has some prior thoughts on this.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:canova, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

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

I experimented using pthread_self instead of gettid at the time but stopped working on it after encountering some issues:

1. pthread_self returns an opaque value as oppose to gettid. It might make it harder to see when we need the real tid number after capturing a profile.
2. If I remember correctly, it broke some things in the frontend. I was suspecting that the number wasn't getting serialized properly into the buffer.

Although second issue can be solved quickly, I still have doubts on the first one. Julien suggested that we could use a thread local storage for this as well to make the consecutive accesses a lot faster. It's worth experimenting with that.

Comment 4

[Julien Cristau [:jcristau]]

Attachment: Bug 1841030 - cache the thread id in thread-local storage

Comment 5

[Julien Wajsberg [:julienw]]

Profiling: https://browserbench.org/Speedometer3.0/?iterationCount=20&suite=TodoMVC-Lit

Profile from latest central: https://share.firefox.dev/3QJdkJ8
Profile with the patch: https://share.firefox.dev/3wolcZX

We can clearly see that the syscall function is much less present. Also the profiler category goes from 12% to 7.7% (-34%).

Comment 6

[Julien Wajsberg [:julienw]]

Nazım and I were curious about Android, so here is a profile on the same workload on firefox Nightly (build from May 8) on my Android phone (Android 12):
https://share.firefox.dev/4dCUzkA

It looks like all profiler-related syscall calls come from the backtrace capture, no gettid spotted there.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f8f4ab08cbd0
cache the thread id in thread-local storage r=profiler-reviewers,canaltinova

Comment 8

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/f8f4ab08cbd0