Rethink use of thread_local #18678

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:

• #18538 (comment)
• Maybe #14669
• Maybe #17247

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).

Could be relevant: https://stackoverflow.com/questions/13106049/what-is-the-performance-penalty-of-c11-thread-local-variables-in-gcc-4-8

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?

For some reason it seems to cause a slowdown from 6 minutes to 60 minutes. I don't know where that came from, but if caused by 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.

Can someone suffering from (assumed) thread_local related performance issues please test #18851?

Closing as there is no thread_local issue (see #18538 (comment)).