-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Add ETW events for recovering syntax trees #38194
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
Conversation
return RecoverRoot(stream, cancellationToken); | ||
if (RoslynEventSource.Instance.IsEnabled(EventLevel.Informational, EventKeywords.None)) | ||
{ | ||
RoslynEventSource.Instance.BlockStart(_containingTree.FilePath, FunctionId.Workspace_Recoverable_RecoverRootAsync, blockId: 0); |
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.
Is there a reason to keep using RoslynEventSource.Instance
vs. capturing it in a local?
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.
Not especially. I just used the pattern seen in similar features for other libraries we ship.
} | ||
finally | ||
{ | ||
if (RoslynEventSource.Instance.IsEnabled(EventLevel.Informational, EventKeywords.None)) |
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.
Seems odd at a glance to check this here. Naiively I'd say that if the check for IsEnabled(EventLevel.Informational, EventKeywords.None))
was true
inside the try
block then we should execute the body of this block period. Not re-check the value again. Checking the value in both places just seems to open the possibility that we'd have unmatched data points in the trace (start but no end, end but no start, etc ...)
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.
Mismatched events is always a possibility (sometimes events get dropped by the OS before we even have a chance to log them). The pattern used here was modeled after the pattern used in vs-threading, e.g. https://github.com/microsoft/vs-threading/blob/e213c20ec8d58d5a32e23739103ccfc22bccbc89/src/Microsoft.VisualStudio.Threading/JoinableTask.cs#L841-L891. I'm not sure what impact deviating from this would have, but I can give one example of where the current behavior might be desired: if the user stops a performance trace while one or more trees is in the process of being deserialized.
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.
Also on the other side, if a user starts a performance trace while the tree is being deserialized, we will see the time it took to deserialize that tree even though it started before the performance trace started capturing data.
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.
Closes #37477
The steps for manually recording traces have already been updated to enable the provider.