Use sync.Pools in otlplog transforms

[MrAlias]

Could we use sync.Pools to reduce the amount of heap allocation? E.g. ResourceLogs could return a functions that would return the pooled maps and slices back to their pools.

If you think that it is possible and it is a good idea then this should be tracked as a separate issue.

_Originally posted by @pellared in https://github.com/open-telemetry/opentelemetry-go/pull/5191#discussion_r1560549956_

[hiroyaonoe]

I want to work on this! Should I update ScopeLogs as well? https://github.com/open-telemetry/opentelemetry-go/blob/fe3de7059e19a0e88c7e8b342ed345e50df94aa3/exporters/otlp/otlplog/otlploghttp/internal/transform/log.go#L56

[MrAlias]

I want to work on this! Should I update ScopeLogs as well?

https://github.com/open-telemetry/opentelemetry-go/blob/fe3de7059e19a0e88c7e8b342ed345e50df94aa3/exporters/otlp/otlplog/otlploghttp/internal/transform/log.go#L56

I would start by only pooling the maps.

[MrAlias]

This needs to be applied at to the template to address both HTTP and gRPC: https://github.com/open-telemetry/opentelemetry-go/tree/main/internal/shared/otlp/otlplog/transform

[kenanfarukcakir]

Hi @MrAlias, I am working on an application that collects logs from a kubernetes node and we plan to export these logs to OpenTelemetry Collector using go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp. When the log frequency increases, I've observed a dramatic increase in the cpu usage of my application.

Got the cpu profile, and it seems related to this issue.

Seems like too much allocation is made and that keeps the GC under pressure. I'd like to work on this and appreciate any direction.