Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The typical usage for logs presents the opportunity for hotspots that don't exist in traces or metrics.
The main use case we want to support is writing log appenders, which bridge other log APIs / frameworks into opentelemetry. Its very typical for these frameworks to have the notion of named loggers, which maps nicely to OpenTelemetry instrumentation scope name. However, this requires that appender implementations obtain a
Logger
instance for each log record processed. Here's an example. Its not typical to obtain a new tracer or meter for each span / measurement, so optimizing this area has not been a priority.This code path is currently suboptimal, particularly in terms of allocations, since it requires creating a new SdkLoggerBuilder, which creates a new InstrumentationScopeInfoBuilder and a new InstrumentationScopeInfo.
There are a couple of obvious ways to optimize this. This PR establishes a benchmark representative of the typical appender use case to evaluate potential performance improvements.
Baseline performance on my machine: