Skip to content

*** 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

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ToddGrun
Copy link
Contributor

@ToddGrun ToddGrun commented Apr 25, 2025

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

Here's the data I'm looking at and hoping to improve:

image

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

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
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 25, 2025
internal VisualStudioPortableExecutableReference(
VisualStudioMetadataReferenceManager provider,
MetadataReferenceProperties properties,
string fullPath,
FileChangeTracker? fileChangeTracker)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

fileChangeTracker

This was always null, so the FileChangeTracker class ended up not being used anywhere.

{
private sealed partial class VisualStudioPortableExecutableReference
{
private class FileTimeStampProvider
Copy link
Member

Choose a reason for hiding this comment

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

sealed?

Copy link
Contributor Author

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));
Copy link
Member

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?

Copy link
Contributor Author

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)

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants