Merely compiling Bitcoin Core with thread_local seems to correlate with massively degraded performance for both the RPC and P2P interface on low-end machines. See for example:
If thread_local really is the source of the performance degradation, it should be disabled by default and only enabled by --enable-debug (for use in lock order debugging).
Yes, it’s onlly used in one place, given how static our thread setup is I think we could easily replace it with a map of thread id to name.
Though naively I’d expect thread-local to be faster than a mutex-protected map. I’m surprised: do we really look up the thread name that often that this matters?
thread_local, this is unacceptable.
It’s only used in one place. Do we have statistics how often these are called?
Or does using thread_local at all, say, even in a place that is never called (or only once), add execution overhead throughout the entire program?
I cannot quite reproduce this locally FWIW. Someone with an affected configuration should do a bit more probing.
Labels
Brainstorming