Excellent points about the initialization order fiasco. I've been bitten by this in embedded systems where startup timing is critical.

One thing I'd add: the guard overhead can actually matter in high-frequency scenarios. I once profiled a logging singleton that was called millions of times per second in a real-time system - the atomic check was showing up as ~3% CPU. But your point stands: if you're hitting that bottleneck, you probably want to reconsider the architecture entirely.

The lazy initialization guarantee is usually worth more than the performance gain, especially since most singletons aren't accessed in tight loops. The static member approach feels like premature optimization unless you've actually measured the guard overhead in your specific use case.

Yes definitely not dismissing the lock overhead, but I wanted to bring attention to the implicit false equivalence made in the post. That said, I am surprised the lock check was showing up and not the logging/formatting functions.