Golang Go语言中这两个 zap 的 bench 结果为什么差那么多？
Golang Go语言中这两个 zap 的 bench 结果为什么差那么多？
差了一个数量级
go test -run=NONE -bench=“Benchmark_Zap”
goos: windows
goarch: amd64
pkg: bench
cpu: Intel® Xeon® 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
更多关于Golang Go语言中这两个 zap 的 bench 结果为什么差那么多？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
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.
我刚才也 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
在Golang中，zap日志库因其高性能和灵活性而受到青睐。关于你提到的zap的bench（基准测试）结果差异显著的问题，这通常可能由以下几个因素导致：
-
测试配置与环境：确保基准测试在相同的硬件和操作系统环境下进行，且没有其他进程干扰测试结果。不同的Go版本或编译器优化也可能导致性能差异。
-
日志级别与输出：zap支持不同的日志级别（Debug、Info、Warn等），不同级别下的日志处理开销不同。此外，如果测试中包含日志输出到文件或网络，I/O操作也会显著影响性能。
-
日志格式与内容：复杂的日志格式或大量日志字段的序列化会增加处理时间。确保基准测试中的日志内容一致，以便准确比较。
-
并发与锁竞争：如果基准测试涉及并发写入日志，zap内部可能使用锁来保证线程安全，这会增加开销。测试时应考虑并发级别对性能的影响。
-
代码与库的版本：zap库本身可能在不同版本间进行了性能优化或修复。确保使用的库版本一致，或比较的是有代表性的、经过充分优化的版本。
综上，要准确分析zap基准测试结果的差异，需要仔细控制测试条件，包括环境、配置、日志级别与内容等。同时，查阅zap的更新日志和性能优化文档，了解可能的变化原因。
