Hello everybody,
I’ve been constructing HaloLog for 3 years. Its first benchmarks ran on my older Twelfth-generation Intel Core i7, and for the previous two years it has been operating inside my interoperability mission whereas I continued profiling and rebuilding the engine beneath it.
HaloLog is now public:
The quantity that can most likely get probably the most consideration is 23.9 ns/op. That was the measured price of manufacturing a whole structured JSON document on the printed benchmark machine. In the identical suite, HaloLog reported 0 B/op and 0 allocs/op in each measured situation.
However the quantity is just not the principle cause I’m posting right here.
I would like the Go group to look at whether or not the declare survives outdoors my machine and outdoors the workloads I chosen.
The benchmarks encode and dispatch full JSON information containing a timestamp, degree, message, and typed fields to io.Discard. They measure the logger’s encoding and dispatch path, not disk or community throughput. The repository publishes the {hardware}, Go model, configurations, methodology, and identified variations between the in contrast loggers.
I’ve tried to make the claims troublesome to protect by chance. There are allocation guards, race-enabled CI, fuzz targets, byte-identity checks between the 2 encoding paths, output-contract checks, and deterministic checks for the code generator.
The overview has already produced a helpful correction. A Zap maintainer identified that Zap’s personal benchmarks use a unique timestamp encoder. Testing it improved Zap by 14.8% within the one-field case and 12.5% within the request-scoped case on my Home windows run. That configuration is now being handled individually as a result of it adjustments the timestamp’s wire illustration.
That’s the type of overview I’m searching for.
HaloLog additionally consists of halologgen. It generates schema-typed logging facades in order that subject names and worth sorts grow to be compile-time contracts as an alternative of repeated string keys all through the codebase.
If you happen to work on Go efficiency, observability, runtime internals, or high-throughput programs, attempt to break it:
git clone GitHub – Go-Gen-Ecosystem/halolog: Zero-allocation structured logging for Go – 0 allocs/op on the recent path, guarded by dedicated checks · GitHub
cd halolog/benchmarks
go check -bench=. -benchmem -count=5 .
Discover an allocation. Produce incorrect JSON. Discover a race, an unfair configuration, or a workload the place the structure loses. If you happen to report the Go model, {hardware}, command, and uncooked output, I’ll reproduce it and publish the end result, together with corrections.
I wrote extra concerning the structure, verification work, and what the 23.9 ns/op end result does and doesn’t show right here:
Full benchmark methodology:
