Ask questionsConsider run time performance
If we want to push this to 1.0 (#38), we really need to make some intentional decisions about performance. The API as it stands was designed largely without considering performance, and (surprise!) it shows.
glogr_benchmark_test.go:
package bench
import (
"flag"
"os"
"testing"
"github.com/go-logr/glogr"
"github.com/go-logr/logr"
"github.com/golang/glog"
)
func init() {
flag.Set("v", "1")
flag.Set("logtostderr", "true")
os.Stderr, _ = os.Open("/dev/null")
}
func BenchmarkGlogInfoOneArg(b *testing.B) {
for i := 0; i < b.N; i++ {
glog.Infof("this is a %s", "string")
}
}
func BenchmarkGlogrInfoOneArg(b *testing.B) {
var log logr.Logger = glogr.New()
for i := 0; i < b.N; i++ {
log.Info("this is", "a", "string")
}
}
func BenchmarkGlogInfoSeveralArgs(b *testing.B) {
for i := 0; i < b.N; i++ {
glog.Infof("multi: bool %t, string %s, int %d, float %f, struct %v",
true, "str", 42, 3.14, struct{ X, Y int }{93, 76})
}
}
func BenchmarkGlogrInfoSeveralArgs(b *testing.B) {
var log logr.Logger = glogr.New()
for i := 0; i < b.N; i++ {
log.Info("multi",
"bool", true, "string", "str", "int", 42,
"float", 3.14, "struct", struct{ X, Y int }{93, 76})
}
}
func BenchmarkGlogInfoV0(b *testing.B) {
for i := 0; i < b.N; i++ {
glog.V(0).Infof("multi: bool %t, string %s, int %d, float %f, struct %v",
true, "str", 42, 3.14, struct{ X, Y int }{93, 76})
}
}
func BenchmarkGlogrInfoV0(b *testing.B) {
var log logr.Logger = glogr.New()
for i := 0; i < b.N; i++ {
log.V(0).Info("multi",
"bool", true, "string", "str", "int", 42,
"float", 3.14, "struct", struct{ X, Y int }{93, 76})
}
}
func BenchmarkGlogInfoV9(b *testing.B) {
for i := 0; i < b.N; i++ {
glog.V(9).Infof("multi: bool %t, string %s, int %d, float %f, struct %v",
true, "str", 42, 3.14, struct{ X, Y int }{93, 76})
}
}
func BenchmarkGlogrInfoV9(b *testing.B) {
var log logr.Logger = glogr.New()
for i := 0; i < b.N; i++ {
log.V(9).Info("multi",
"bool", true, "string", "str", "int", 42,
"float", 3.14, "struct", struct{ X, Y int }{93, 76})
}
}
Running this:
goos: linux
goarch: amd64
pkg: github.com/go-logr/glogr/bench
cpu: Intel(R) Xeon(R) W-2135 CPU @ 3.70GHz
BenchmarkGlogInfoOneArg-6 713682 1675 ns/op
BenchmarkGlogrInfoOneArg-6 251154 4761 ns/op
BenchmarkGlogInfoSeveralArgs-6 527288 2285 ns/op
BenchmarkGlogrInfoSeveralArgs-6 167934 7114 ns/op
BenchmarkGlogInfoV0-6 529798 2286 ns/op
BenchmarkGlogrInfoV0-6 164413 7293 ns/op
BenchmarkGlogInfoV9-6 46018132 25.70 ns/op
BenchmarkGlogrInfoV9-6 8412883 142.2 ns/op
So it's notably slower. All of the variadic args escape to the heap, including the string keys (which regular glog does not suffer). But doesn't account for enough.
V() calls that are not taken also expand all their variadic args used.
Some of this is attributable to glogr being very dumb and wasteful (clone() on every call) but it's not clear how much. Before we call it 1.0 we need to do some homework.
Answer
questions
thockin
Switching benchmark to Discard():
Before:
BenchmarkInfoOneArg-6 309439507 3.628 ns/op
BenchmarkInfoSeveralArgs-6 103684642 11.17 ns/op
BenchmarkV0Info-6 10411196 115.8 ns/op
BenchmarkV9Info-6 9963486 118.2 ns/op
BenchmarkError-6 82650194 12.14 ns/op
BenchmarkWithValues-6 220570576 5.585 ns/op
BenchmarkWithName-6 723292029 1.441 ns/op
After:
BenchmarkInfoOneArg-6 28276839 46.68 ns/op
BenchmarkInfoSeveralArgs-6 9974653 114.4 ns/op
BenchmarkV0Info-6 11343361 118.7 ns/op
BenchmarkV9Info-6 10160247 117.6 ns/op
BenchmarkError-6 10033260 113.5 ns/op
BenchmarkWithValues-6 21537408 59.31 ns/op
BenchmarkWithName-6 502713001 2.189 ns/op
Related questions
No questions were found.