这两个 zap 的 bench 结果为什么差那么多?

115 天前
 lysShub

https://go.dev/play/p/2sos96ziKjY

1293 次点击
所在节点    Go 编程语言
8 条回复
lysShub
115 天前
差了一个数量级

go test -run=NONE -bench="Benchmark_Zap"
goos: windows
goarch: amd64
pkg: bench
cpu: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz
Benchmark_Zap/sink-12 17067564 68.55 ns/op 2 B/op 0 allocs/op
Benchmark_Zap/new-12 1000000 1038 ns/op 8 B/op 2 allocs/op
PASS
ok bench 3.021s
matrix1010
115 天前
discard 和 JSON encode 速度必然不一样。不过这个挺适合测试 LLM 的代码理解与基本逻辑能力,GPT-4o 3 次回答中 2 次都指出“sink” 应该更快 Potentially faster due to minimal overhead from discarding logs (discard:). 但 Gemini 1.5 pro 回答了 3 次全部错误,虽然他在分析代码时也指出了 discard ,但在后面推断哪个更快时直接忽略了这一点:Due to the simpler and more direct configuration in the `new` benchmark, it is **likely to be slightly faster** than the `sink` benchmark.
lysShub
115 天前
@matrix1010 两个都是 discard
matrix1010
115 天前
@lysShub 确实,那最好 pprof 看一下
lysShub
115 天前
@matrix1010 破案了,sink 那个的配置里面设置了 sample ,实际只有十分钟一的数据被真正序列化
lysShub
115 天前
十分之一
matrix1010
115 天前
我刚才也 pprof 了一下你的代码,大头在 CheckEntity.Write 上。看了一眼 zap 代码其实是 1 秒内百分之一"with the same level and message in the same second, it will log every 100th entry with the same level and message in the same second." 不 sample 你的第二个应该更快一点,因为默认没有 caller
keakon
115 天前
zap 挺慢的,基本没啥奇技淫巧
https://github.com/keakon/golog/?tab=readme-ov-file#result

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1059666

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX