3 ms·
Oof. We just converted all of our logging to zap[0] to get structured JSON logging for downstream parsing. Wonder how the perf stacks up. [0]: https://github.c
by kusha 3y ago
Oof. We just converted all of our logging to zap[0] to get structured JSON logging for downstream parsing. Wonder how the perf stacks up.
[0]: https://github.com/uber-go/zap https://github.com/uber-go/zap
- tony_cannistra 3y agoIt looks like they've included slog in their performance benchmarks, which show zap as considerably more performant (though I don't really understand the benchmark).
- llimllib 3y agohttp://bench.zerolog.io/ http://bench.zerolog.io/ Is a useful set of benchmarks
- yencabulator 3y agoThat test puts a lot of stuff through `slog.Any`, while the zap version uses more strongly-typed variants, so I'm not sure it's a fair comparison. What it comes down to is that zap special cases things like slice-of-int, slice-of-string, slice-of-timestamp, slog doesn't, and the benchmark includes all those special cases. I question whether your typical log statement includes slices. A more fair benchmark would be just scalar types, and zap & slog optimizations there look pretty similar. https://github.com/uber-go/zap/blob/fd37f1f613a87773fc30f719cc2aaf9a0e72d635/benchmarks/slog_test.go#L41 https://github.com/uber-go/zap/blob/fd37f1f613a87773fc30f719... https://github.com/uber-go/zap/blob/fd37f1f613a87773fc30f719cc2aaf9a0e72d635/benchmarks/zap_test.go#L127 https://github.com/uber-go/zap/blob/fd37f1f613a87773fc30f719...