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.

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

Metrics Feature Switch #91767

Merged
merged 3 commits into from
Sep 12, 2023
Merged

Metrics Feature Switch #91767

merged 3 commits into from
Sep 12, 2023

Conversation

tarekgh
Copy link
Member

@tarekgh tarekgh commented Sep 7, 2023

@ghost ghost assigned tarekgh Sep 7, 2023
@tarekgh tarekgh added this to the 8.0.0 milestone Sep 7, 2023
@tarekgh
Copy link
Member Author

tarekgh commented Sep 7, 2023

@eerhardt @noahfalk

Copy link
Member

@noahfalk noahfalk left a comment

Choose a reason for hiding this comment

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

LGTM with a couple questions inline

@@ -52,6 +52,11 @@ protected Instrument(Meter meter, string name, string? unit, string? description
/// <param name="tags">A span of key-value pair tags associated with the measurement.</param>
protected void RecordMeasurement(T measurement, ReadOnlySpan<KeyValuePair<string, object?>> tags)
{
if (!Meter.IsSupported)
Copy link
Member

Choose a reason for hiding this comment

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

Can we avoid adding this check and count on _subscription.First to be null? It looks like you already blocked all the code paths that could have registered a subscription.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, we can do that. According to my understanding (per @eerhardt explanation) jit is going to optimize that in tier two and will fully remove this check. I was hoping when IsSupported is false, the linker can empty the whole method body including accessing the static fields. Let me know if you still think we should remove this check.

Copy link
Member

Choose a reason for hiding this comment

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

Can you confirm the JIT does optimize it as expected. As long as that is confirmed then I have no qualms leaving it there :)

Copy link
Member

Choose a reason for hiding this comment

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

Adding this check will allow the trimmer to remove the rest of the method body, right?

Copy link
Member

Choose a reason for hiding this comment

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

Adding this check will allow the trimmer to remove the rest of the method body, right?

Correct - and all the methods it calls that aren't called elsewhere.

Copy link
Member Author

Choose a reason for hiding this comment

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

I created a simple app using my private built. The app and the runtime were built as a release. I have IsSupported = true to test the normal case. I run it under the debugger, and I am seeing the call Meter.IsSupported is not removed inside RecordMeasurement method. I'll remove this check from there as this is a hot path, we want to avoid regressions there.

image

Copy link
Member

@eerhardt eerhardt left a comment

Choose a reason for hiding this comment

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

Should we also have a trimming test that ensures certain things are trimmed?

Can you show a before and after size comparison (maybe using ILSpy or https://github.com/MichalStrehovsky/sizoscope) that shows what is all trimmed when this switch is set?

Copy link
Member

@eerhardt eerhardt left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks, @tarekgh.

@tarekgh tarekgh merged commit 3aeefbd into dotnet:main Sep 12, 2023
106 checks passed
@tarekgh
Copy link
Member Author

tarekgh commented Sep 12, 2023

/backport to release/8.0

@github-actions
Copy link
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6165846484

@github-actions
Copy link
Contributor

@tarekgh backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: Metrics Feature Switch
Using index info to reconstruct a base tree...
M	docs/workflow/trimming/feature-switches.md
M	src/libraries/System.Diagnostics.DiagnosticSource/src/System.Diagnostics.DiagnosticSource.csproj
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Diagnostics.DiagnosticSource/src/System.Diagnostics.DiagnosticSource.csproj
CONFLICT (content): Merge conflict in src/libraries/System.Diagnostics.DiagnosticSource/src/System.Diagnostics.DiagnosticSource.csproj
Auto-merging docs/workflow/trimming/feature-switches.md
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Metrics Feature Switch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions
Copy link
Contributor

@tarekgh an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants