-
Notifications
You must be signed in to change notification settings - Fork 764
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.
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-metrics] Remove ExemplarFilter classes #5408
Merged
CodeBlanch
merged 6 commits into
open-telemetry:main
from
CodeBlanch:sdk-metrics-removefilterclasses
Mar 5, 2024
Merged
Changes from 3 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
a6e5a38
Remove ExemplarFilter classes.
CodeBlanch 19271f5
Tweak.
CodeBlanch cd9ab09
Merge branch 'main' into sdk-metrics-removefilterclasses
CodeBlanch 8f9d5f0
Code review.
CodeBlanch cc00c52
Merge branch 'sdk-metrics-removefilterclasses' of https://github.com/…
CodeBlanch 08a51f8
Tweaks.
CodeBlanch File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
27 changes: 0 additions & 27 deletions
27
src/OpenTelemetry/Metrics/Exemplar/AlwaysOffExemplarFilter.cs
This file was deleted.
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would probably be faster to use
if
thanswitch
? If yes, we should optimize the non-exemplar updates.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found an old benchmark saying that switch usually will be faster cause compiler will create jump table for switch statement: https://www.blackwasp.co.uk/SpeedTestIfElseSwitch.aspx.
I guess the assembly generated for if/switch here will be identical given there are only 3 cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you know your most common condition, you can make that the very first check. That way you only have to check
if(true)
to execute the most common path. That might be faster than the jump table lookup. In fact, you can use a mixed approach as well. Something like this:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the code to use an
if
block. But it has been interesting to try and prove what is best.Here are some benchmarks run without PGO enabled:
Here are some benchmarks run with PGO enabled:
PGO is smart enough to see that one value is used repeatedly and optimize the code on its own for that value. It is great for what we're doing here.
I ended up going with the
if
because PGO may not be there in AOT deployments/older runtimes so it seems best to optimize for it not being there.