Use a variable-size array to represent ordered labels in maps

[jmacd]

Rather than using a label encoder to encode a unique representation of the label set, we can use an interface{} containing an array value of the appropriate size. (This was described as "use dangerous reflection black magic" in the Metrics SIG meeting notes today.) This improve benchmarks significantly. The code has been hand-written for up to 10 labels to avoid the overhead of reflect.

Before:

goos: darwin
goarch: amd64
pkg: go.opentelemetry.io/otel/sdk/metric
BenchmarkLabels_1-8    	 4147288	       266 ns/op	      80 B/op	       2 allocs/op
BenchmarkLabels_2-8    	 2574391	       447 ns/op	      96 B/op	       2 allocs/op
BenchmarkLabels_4-8    	 1570831	       806 ns/op	     144 B/op	       2 allocs/op
BenchmarkLabels_8-8    	  833871	      1432 ns/op	     224 B/op	       2 allocs/op
BenchmarkLabels_16-8   	  445599	      2703 ns/op	     400 B/op	       2 allocs/op

After:

goos: darwin
goarch: amd64
pkg: go.opentelemetry.io/otel/sdk/metric
BenchmarkLabels_1-8    	 9424884	       124 ns/op	      96 B/op	       2 allocs/op
BenchmarkLabels_2-8    	 7479254	       163 ns/op	     144 B/op	       2 allocs/op
BenchmarkLabels_4-8    	 5067748	       236 ns/op	     240 B/op	       2 allocs/op
BenchmarkLabels_8-8    	 3274238	       359 ns/op	     432 B/op	       2 allocs/op
BenchmarkLabels_16-8   	  763551	      1377 ns/op	    1584 B/op	       3 allocs/op

[jmacd]

Note that use of an array-valued key makes map lookups more expensive, but this is still an overall performance win.

Before:

BenchmarkInt64CounterAdd-8                             	10995777	       108 ns/op	       0 B/op	       0 allocs/op
BenchmarkInt64CounterHandleAdd-8                       	72600636	        16.4 ns/op	       0 B/op	       0 allocs/op
BenchmarkFloat64CounterAdd-8                           	10173048	       112 ns/op	       0 B/op	       0 allocs/op
BenchmarkFloat64CounterHandleAdd-8                     	63691292	        18.8 ns/op	       0 B/op	       0 allocs/op

After:

BenchmarkInt64CounterAdd-8                             	 7974315	       151 ns/op	       0 B/op	       0 allocs/op
BenchmarkInt64CounterHandleAdd-8                       	71714146	        16.6 ns/op	       0 B/op	       0 allocs/op
BenchmarkFloat64CounterAdd-8                           	 7449758	       157 ns/op	       0 B/op	       0 allocs/op
BenchmarkFloat64CounterHandleAdd-8                     	63894693	        18.6 ns/op	       0 B/op	       0 allocs/op

[jmacd]

Note that this change removes the caching of encoded labels. It's possible to regain this by adding support for the label set to cache the encoding for >=1 label encoder, instead. I did it that way in OTEP 78, see here:

https://github.com/jmacd/opentelemetry-go/blob/8bed2e14df7f9f4688fbab141924bb786dc9a3a1/api/context/internal/set.go#L89

[jmacd]

Another note: if the benchmark was to measure the cost of update-to-export of a single metric event, and we compare with previous "single encoding" optimization, this approach costs more overall because we're computing two encodings (one for the map and one for the export). I'm still happy with this direction because it reduces confusion about handling label encoders.

[jmacd]

We can slightly optimize this code as noted here: https://github.com/open-telemetry/opentelemetry-go/pull/523/files#diff-4c3de179542bac3c5ceacd2090215160R371

As there is a forthcoming OTEP proposing to remove LabelSet, I decided to leave several potential optimizations out.

[jmacd]

@bogdandrutu please 👀.

[krnowak]

Mostly looks good, but have some nits and questions.

[bogdandrutu]

Overall this looks like an improvement for me.