3 ms·
I'm the author of fgtrace, happy to answer any questions :). I've also posted a few more comments in this twitter thread: https://twitter.com/felixge/status/15
by felixge 4y ago
I'm the author of fgtrace, happy to answer any questions :).
I've also posted a few more comments in this twitter thread: https://twitter.com/felixge/status/1571850160358965249 https://twitter.com/felixge/status/1571850160358965249
- deleted 4y ago[deleted]
- lanstin 4y agoI use the builtin pprof flame graphs all the time, and since each of the goroutine pools have different stack traces, i can tell them apart. what does this package improve on? Wall time instead of CPU time? It isnt immediately obvious to me what the extra info is?
- felixge 4y agoThe main difference is that you get a timeline (flame chart) rather than flame graph. This allows you to understand the order in which operations are taking place. You also get walltime (instead of CPU time), so you can debug Off-CPU performance bottlenecks (e.g. database calls) without the need for additional instrumentation. Last but not least you get everything broken down per-goroutine, so you can understand which operations are executed concurrently vs sequentially. The Go CPU profiler is great for reducing CPU utilization. But unless you're CPU-bound, it's not very useful for improving latency. fgtrace is trying to help with that.