|author||Jonathan Amsterdam <firstname.lastname@example.org>||Fri Jan 13 12:43:19 2023 -0500|
|committer||Jonathan Amsterdam <email@example.com>||Tue Jan 24 14:29:47 2023 +0000|
slog: re-run slog, zerolog, zap benchmarks slog is as fast as zap, as expected (output from benchstat): Attrs/fastText_discard/5_args-8 518ns ± 3% 486ns ± 7% ~ (p=0.056 n=5+5) Attrs/fastText_discard/10_args-8 919ns ±13% 918ns ± 5% ~ (p=0.841 n=5+5) slog is slower than zerolog: Attrs/fastText_discard/5_args-8 183ns ± 4% 486ns ± 7% +165.39% (p=0.008 n=5+5) Attrs/fastText_discard/10_args-8 283ns ± 4% 918ns ± 5% +224.63% (p=0.008 n=5+5) These numbers understate zerolog's advantage, because it produces JSON and the slog handler used for benchmarking just concatenates text. With the slog JSONHandler, the times are 925ns for 5 args and 1630ns for 10 args. Most of zerolog's advtange is likely due to its design, which trades flexibility and safety for speed. Also, zerolog doesn't lock, but that seems to add only about 200ms to the time. There are no obvious improvements to be made in the slog JSON implementation, but we will try to improve it by profiling. It's important to remember that these benchmarks discard the output, neglecting I/O latency, which can be significant. Change-Id: Ie408873465055892e9b70a98aff5c1568ee4175b Reviewed-on: https://go-review.googlesource.com/c/exp/+/461998 Reviewed-by: Alan Donovan <firstname.lastname@example.org> TryBot-Result: Gopher Robot <email@example.com> Run-TryBot: Jonathan Amsterdam <firstname.lastname@example.org>
This subrepository holds experimental and deprecated (in the
old directory) packages.
The idea for this subrepository originated as the
pkg/exp directory of the main repository, but its presence there made it unavailable to users of the binary downloads of the Go installation. The subrepository has therefore been created to make it possible to
go get these packages.
Warning: Packages here are experimental and unreliable. Some may one day be promoted to the main repository or other subrepository, or they may be modified arbitrarily or even disappear altogether.
In short, code in this subrepository is not subject to the Go 1 compatibility promise. (No subrepo is, but the promise is even more likely to be violated by go.exp than the others.)