-
Notifications
You must be signed in to change notification settings - Fork 4.1k
*** WIP: Significantly reduce FileUtilities.GetFileTimeStamp calls #78321
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
base: main
Are you sure you want to change the base?
Conversation
In draft mode until: 1) Receive input from Jason on whether this approach is reasonable 2) Get results from speedometer run on test insertion indicating this indeed helps If those both happen, will update with more information
internal VisualStudioPortableExecutableReference( | ||
VisualStudioMetadataReferenceManager provider, | ||
MetadataReferenceProperties properties, | ||
string fullPath, | ||
FileChangeTracker? fileChangeTracker) |
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.
{ | ||
private sealed partial class VisualStudioPortableExecutableReference | ||
{ | ||
private class FileTimeStampProvider |
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.
sealed?
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.
will do in next commit
context.FileChanged += self.OnContextFileChanged; | ||
|
||
return context; | ||
}, (watcher, 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.
how expensive is this? should we consider doing outside of lock?
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.
This is cheap (at least for the FileChangeWatcher.CreateContext implementation)
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.
Unless you were talking about the GetFileTimeStamp call, which can be expensive. I could be convinced to do that outside the lock and then reobtain the lock.
In draft mode until:
If those both happen, will update with more information
Here's the data I'm looking at and hoping to improve:
Locally, I see the number of calls to FileUtilities.GetFileTimeStamp in this callstack when opening Roslyn.sln go from 64,195 to 1,511
Test insertion (commit 2): https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/631765