Pro tip: if you think you will need to profile/trace any natively compiled code at runtime (e.g. some kind of long running service in production) then for the love of god, please don't enable "omit frame pointer" - it can mean the difference between actually readable callstacks/flame graphs and garbage. The days of it having a huge impact on performance are gone, at least from my experience - disabling omitting frame pointer has made no significantly measurable difference to any services I have run in recent years, though you should always confirm that is true for your own case.<p>So while this article is about Go, it definitely applies to C/C++ as well.
It was interesting to look directly at the source code linked in the article for stack unwiding [1]. In particular, it's neat to see how thoroughly documented this file is. Reminds me of poking around the SQLite codebase.<p>[1] <a href="https://github.com/golang/go/blob/6b8b7823c7fd9f3f2317f657120dc2e965d97b77/src/runtime/traceback.go#L32">https://github.com/golang/go/blob/6b8b7823c7fd9f3f2317f65712...</a>
Would this speed up capturing stack traces? The use case I have in mind is stack traces for logging. The Zap logger has a mild warning [1] about stack traces being relatively expensive.<p>[1]: <a href="https://pkg.go.dev/go.uber.org/zap#Stack" rel="nofollow">https://pkg.go.dev/go.uber.org/zap#Stack</a>