| I’m sharing HaloLog, a structured logger I have developed for three years and run inside an interoperability project for the past two. Its goal is low-overhead structured logging without trading away JSON correctness, race safety, configured PII masking, or compile-checked telemetry fields. This is a public release and a request for independent reproduction of the measurements, not a claim about disk or network throughput. The committed suite compares HaloLog with zap, zerolog, slog, logrus, and phuslu/log while encoding and dispatching complete JSON records to io.Discard. On the published Go 1.27 linux/amd64 host, HaloLog measured 23.9 ns/op for one complete record and 0 B/op, 0 allocs/op across all its measured scenarios. The repository documents the hardware, configurations, methodology, known differences, and correctness guardrails. These are results for those workloads and that host, not a universal performance claim. If you reproduce or falsify a result, please include the Go version, hardware, command, and raw output. Useful counterexamples include an allocation, invalid JSON, a race, an unfair competitor configuration, or a workload in which HaloLog performs worse. [link] [留言] |
Benchmarking HaloLog against zap, zerolog, slog, logrus, and phuslu/log: 23.9 ns/op
Related
Why Do Japanese Train Drivers Keep Pointing at Things?
Who Saw the Connection? #04 — Railways × Human Factors × Software If you spend enough time on a railway platform in Japan, you may notice something that looks oddly theatrical. A conductor checks the platform, points down it, says something aloud, looks toward another reference point, and repeats
How I Built End To End Observability Stack with OpenTelemetry, Prometheus, Grafana, Loki, and Jaeger
When an application is running, knowing that it is up does not necessarily mean knowing what it is doing. For example, imagine an API request that takes several seconds to complete. We would want to answer questions such as: Is the application receiving more requests than usual? What happened dur
Switching from GPT-5.6 Sol to GPT-6 Astra: Start with Medium Effort
GPT-6 Astra at high reasoning effort produced the implementation I decided to keep. I still plan to use medium effort by default. High handled the interactions between retries and persisted state more completely, but its implementation run took about 48 minutes against medium's 31. In a separate re