Hi everyone,
I have been building HaloLog for three years. Its first benchmarks ran on my older 12th-generation Intel Core i7, and for the past two years it has been running inside my interoperability project while I continued profiling and rebuilding the engine underneath it.
HaloLog is now public:
The number that will probably get the most attention is 23.9 ns/op. That was the measured cost of producing a complete structured JSON record on the published benchmark machine. In the same suite, HaloLog reported 0 B/op and 0 allocs/op in every measured scenario.
But the number is not the main reason I am posting here.
I want the Go community to examine whether the claim survives outside my machine and outside the workloads I selected.
The benchmarks encode and dispatch complete JSON records containing a timestamp, level, message, and typed fields to io.Discard. They measure the logger’s encoding and dispatch path, not disk or network throughput. The repository publishes the hardware, Go version, configurations, methodology, and known differences between the compared loggers.
I have tried to make the claims difficult to preserve accidentally. There are allocation guards, race-enabled CI, fuzz targets, byte-identity tests between the two encoding paths, output-contract tests, and deterministic tests for the code generator.
The review has already produced a useful correction. A Zap maintainer pointed out that Zap’s own benchmarks use a different timestamp encoder. Testing it improved Zap by 14.8% in the one-field case and 12.5% in the request-scoped case on my Windows run. That configuration is now being treated separately because it changes the timestamp’s wire representation.
That is the kind of review I am looking for.
HaloLog also includes halologgen. It generates schema-typed logging facades so that field names and value types become compile-time contracts instead of repeated string keys throughout the codebase.
If you work on Go performance, observability, runtime internals, or high-throughput systems, try to break it:
git clone GitHub - Go-Gen-Ecosystem/halolog: Zero-allocation structured logging for Go - 0 allocs/op on the hot path, guarded by committed tests · GitHub
cd halolog/benchmarks
go test -bench=. -benchmem -count=5 .
Find an allocation. Produce incorrect JSON. Find a race, an unfair configuration, or a workload where the architecture loses. If you report the Go version, hardware, command, and raw output, I will reproduce it and publish the result, including corrections.
I wrote more about the architecture, verification work, and what the 23.9 ns/op result does and does not prove here:
Full benchmark methodology: