Pool metric options created in the otelhttp instrumentation

[MadVikingGod]

Pooling the options created by otelhttp instrumentation should reduce allocations and improve performance.

Tasks

• Use a pool when creating metric options.
• Create benchmark showing this does reduce allocations.

Originally posted by @MrAlias in #5818 (comment)

[vordimous]

This looks to be a straightforward pool for the objects created in RecordMetrics(). What is the best way to benchmark the number of allocations? I would like to take on this issue.

[dmathieu]

A benchmark with the ReportAllocs option will allow you to compare the number of allocations between two different implementations.

See this as an example:

opentelemetry-go-contrib/instrumentation/net/http/otelhttp/internal/semconv/bench_test.go

Line 19 in a59214f

func BenchmarkHTTPServerRequest(b *testing.B) {

[vordimous]

I have implemnted two benchmark functions in env_test.go that run the same code as the TestHTTPServerDoesNotPanic(). I added a benchmark for the unpooled code and pooled code with both reporting 0 allocs/op. I may have done something wrong or identified that pooling isn't needed?

BenchmarkRecordMetricsPooled-10    	1000000000	         0.0000000 ns/op	       0 B/op	       0 allocs/op
BenchmarkRecordMetrics-10          	1000000000	         0.0000001 ns/op	       0 B/op	       0 allocs/op

Full test results:

Running tool: /opt/homebrew/bin/go test -timeout 30s -run ^(TestHTTPServerDoesNotPanicPooled|TestHTTPServerDoesNotPanic|TestHTTPClientDoesNotPanic)$ go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp/internal/semconv -v --bench . --benchmem

=== RUN   TestHTTPServerDoesNotPanicPooled
=== RUN   TestHTTPServerDoesNotPanicPooled/empty
=== RUN   TestHTTPServerDoesNotPanicPooled/nil_meter
=== RUN   TestHTTPServerDoesNotPanicPooled/with_Meter
--- PASS: TestHTTPServerDoesNotPanicPooled (0.00s)
    --- PASS: TestHTTPServerDoesNotPanicPooled/empty (0.00s)
    --- PASS: TestHTTPServerDoesNotPanicPooled/nil_meter (0.00s)
    --- PASS: TestHTTPServerDoesNotPanicPooled/with_Meter (0.00s)
=== RUN   TestHTTPServerDoesNotPanic
=== RUN   TestHTTPServerDoesNotPanic/empty
=== RUN   TestHTTPServerDoesNotPanic/nil_meter
=== RUN   TestHTTPServerDoesNotPanic/with_Meter
--- PASS: TestHTTPServerDoesNotPanic (0.00s)
    --- PASS: TestHTTPServerDoesNotPanic/empty (0.00s)
    --- PASS: TestHTTPServerDoesNotPanic/nil_meter (0.00s)
    --- PASS: TestHTTPServerDoesNotPanic/with_Meter (0.00s)
=== RUN   TestHTTPClientDoesNotPanic
=== RUN   TestHTTPClientDoesNotPanic/empty
=== RUN   TestHTTPClientDoesNotPanic/nil_meter
=== RUN   TestHTTPClientDoesNotPanic/with_Meter
--- PASS: TestHTTPClientDoesNotPanic (0.00s)
    --- PASS: TestHTTPClientDoesNotPanic/empty (0.00s)
    --- PASS: TestHTTPClientDoesNotPanic/nil_meter (0.00s)
    --- PASS: TestHTTPClientDoesNotPanic/with_Meter (0.00s)
goos: darwin
goarch: arm64
pkg: go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp/internal/semconv
cpu: Apple M1 Max
BenchmarkHTTPServerRequest
BenchmarkHTTPServerRequest-10      	 4002741	       290.8 ns/op	     712 B/op	       2 allocs/op
BenchmarkRecordMetricsPooled
BenchmarkRecordMetricsPooled-10    	1000000000	         0.0000000 ns/op	       0 B/op	       0 allocs/op
BenchmarkRecordMetrics
BenchmarkRecordMetrics-10          	1000000000	         0.0000001 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp/internal/semconv	1.752s

[dmathieu]

Could you open a PR with the code change and benchmark? That would provide the appropriate data to review your analysis.

[vordimous]

@dmathieu I have created the PR with new method and benchmarks: #6394