280eaf33f0
* Use global string map for MatchType.String()
We were unnecessarily creating a new map for each call of String().
This is a 10x improvement in MatchType.String() performance in time,
from 53ns to 4ns on my i7 laptop, and I guess that this method is being
called quite often so why throw out the resources.
I was surprised that benchmark says that there are no allocations made
in the old version.
I also tries using `//go:generate stringer` and the result is even
better, at about 2.8ns, but having to keep the generated code updated
isn't worth the change (at least it's bigger than a small change I was
intended to do)
Benchmark comparison:
name \ time/op old global_map stringer
MatchType_String 53.6ns ± 1% 4.1ns ± 1% 2.8ns ± 1%
name \ alloc/op old global_map stringer
MatchType_String 0.00B 0.00B 0.00B
name \ allocs/op old global_map stringer
MatchType_String 0.00 0.00 0.00
Old benchmark:
goos: darwin
goarch: amd64
pkg: github.com/prometheus/prometheus/pkg/labels
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkMatchType_String 21766578 54.36 ns/op 0 B/op 0 allocs/op
BenchmarkMatchType_String 21742339 53.28 ns/op 0 B/op 0 allocs/op
BenchmarkMatchType_String 21985470 53.37 ns/op 0 B/op 0 allocs/op
BenchmarkMatchType_String 21676282 53.50 ns/op 0 B/op 0 allocs/op
BenchmarkMatchType_String 22075573 53.33 ns/op 0 B/op 0 allocs/op
PASS
ok github.com/prometheus/prometheus/pkg/labels 6.252s
New with global map:
goos: darwin
goarch: amd64
pkg: github.com/prometheus/prometheus/pkg/labels
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkMatchType_String 283412692 4.129 ns/op 0 B/op 0 allocs/op
BenchmarkMatchType_String 294859941 4.091 ns/op 0 B/op 0 allocs/op
BenchmarkMatchType_String 295750158 4.113 ns/op 0 B/op 0 allocs/op
BenchmarkMatchType_String 282827982 4.072 ns/op 0 B/op 0 allocs/op
BenchmarkMatchType_String 292942393 4.047 ns/op 0 B/op 0 allocs/op
PASS
ok github.com/prometheus/prometheus/pkg/labels 8.238s
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
* Use array instead of map
Since MatchType is an iota type, we can safely use an array here.
This solution is even better:
name \ time/op old global_map stringer array
MatchType_String 53.6ns ± 1% 4.1ns ± 1% 2.8ns ± 1% 1.0ns ± 1%
name \ alloc/op old global_map stringer array
MatchType_String 0.00B 0.00B 0.00B 0.00B
name \ allocs/op old global_map stringer array
MatchType_String 0.00 0.00 0.00 0.00
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
* Benchmark all MatchType values
Co-authored-by: Ganesh Vernekar <15064823+codesome@users.noreply.github.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
* Use constants for limits
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Co-authored-by: Ganesh Vernekar <15064823+codesome@users.noreply.github.com>
Co-authored-by: Ganesh Vernekar <15064823+codesome@users.noreply.github.com>
|
||
|---|---|---|
| .. | ||
| exemplar | ||
| gate | ||
| labels | ||
| logging | ||
| modtimevfs | ||
| pool | ||
| relabel | ||
| rulefmt | ||
| runtime | ||
| textparse | ||
| timestamp | ||
| value | ||