There will be a performance cost anyway.

Benchmarking slog with a "no-op" backend vs zerolog shows that slog frontend already brings some overhead. But still it will be great to have a zerolog handler for the libraries which will use slog.

No-Op handler:

type DummyHandler struct{}

func (*DummyHandler) Enabled(context.Context, slog.Level) bool {
	return true
}
func (*DummyHandler) Handle(context.Context, slog.Record) error {
	return nil
}
func (h *DummyHandler) WithAttrs(attrs []slog.Attr) slog.Handler {
	return h
}
func (h *DummyHandler) WithGroup(name string) slog.Handler {
	return h
}

Bench:

func BenchmarkDummy(b *testing.B) {
	ctx := context.Background()
	l := slog.New(&DummyHandler{})
	l = l.With("foo", "bar")
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		l.LogAttrs(ctx, slog.LevelInfo, "hello", slog.String("bar", "baz"))
	}
}

func BenchmarkZerolog(b *testing.B) {
	l := zerolog.New(io.Discard).Level(zerolog.DebugLevel).With().Timestamp().Logger()
	l = l.With().Str("foo", "bar").Logger()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		l.Info().Str("bar", "baz").Msg("hello")
	}
}

Results:

BenchmarkDummy-4     	 1876441	       657.7 ns/op	       0 B/op	       0 allocs/op
BenchmarkZerolog-4   	 4235698	       284.3 ns/op	       0 B/op	       0 allocs/op

In this particular test scenario, slog handler is already 2 times slower while doing nothing in the backend. With a zerolog backend it will then be at least 3 times slower and we must add some time to perform the mapping from slog concepts to zerolog concepts (mapping levels, attributes, ...)

stdlib slog handler for zerolog #571

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions