Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sdk/log: Add BenchmarkLoggerProviderLoggerSame #5599

Closed
wants to merge 2 commits into from
Closed

sdk/log: Add BenchmarkLoggerProviderLoggerSame #5599

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bca335f
sdk/log: Add BenchmarkLoggerProviderLoggerSame
pellared Jul 10, 2024
5243f76
Fix
pellared Jul 10, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions sdk/log/provider_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -308,3 +308,18 @@ func BenchmarkLoggerProviderLogger(b *testing.B) {
b.StopTimer()
loggers[0].Enabled(context.Background(), log.Record{})
}

func BenchmarkLoggerProviderLoggerSame(b *testing.B) {
p := NewLoggerProvider()

b.ResetTimer()
b.ReportAllocs()

var logger log.Logger
for i := 0; i < b.N; i++ {
logger = p.Logger("test", log.WithInstrumentationVersion("v1.2.3"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to our metric benchmarks, this passed option should be allocated outside of the evaluation loop. Otherwise, we are measuring the inefficient misuse of the API.

Copy link
Member Author

@pellared pellared Jul 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise, we are measuring the inefficient misuse of the API.

This is the whole point of the benchmark is to show that such usage introduces a heap allocation. I find it is too easy to use the API in an inefficient way,

I think that it would be better if the user would not need to preallocate instrumentation version in order not introduce a heap allocation.

It would be better if "strightforward" usage (like inlining options) would not introduce performance overhead. I prefer to have an API which makes writing inefficient code harder. At the same time the most straightforward usage should be performant.

Copy link
Member Author

@pellared pellared Jul 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I should add a comment like: "Showcase that not pre-allocating the options slice causes a heap allocation introduced by the compiler"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that is the case, then this seems like a re-hash of the already concluded extensive conversation about how we handle configuration:

Additionally, since we have already discussed this specific detail for the metric signal12 extensively, unless there are new developments, I would prefer to not have the same discussion again. Especially since there is are now 2 stable signals that have set our precedence and a documented policy.

Footnotes

  1. https://github.com/open-telemetry/opentelemetry-go/pull/3971#discussion_r1163272609 ↩

  2. topic of discussion in the April 13 2023 SIG meeting: https://docs.google.com/document/d/1E5e7Ld0NuU1iVvf-42tOBpu2VBBLYnh73GJuITGJTTU/edit#heading=h.9lojwomaurj2 ↩

This comment was marked as outdated.

Sign in to view

Copy link
Member Author

@pellared pellared Jul 11, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am fine using options for things bootstrapping the SDK (creating exporters, providers, processors).

However, I find that using options on code that may be on the hot-path makes it too easy for the callers to write inefficient code. Take notice that log.Record already diverges from these guidelines. Maybe, we should work on an alternate guideline for handling configuration for code that we asses that may be on the hot-path (e.g. when recording a value)?

I also think that there is very low probability that we would need to create logger provider options on the fly in the bridges. If it would occur, we can always create a new API.

I am closing this PR and creating a new issue. Thank you for your insight.

}

b.StopTimer()
logger.Enabled(context.Background(), log.Record{})
}
Loading