You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Avoid acquiring the workspace lock on the UI thread if unneeded
If the project system tells us about a file that's open and we are told
about it on a background thread, we connect the file to the workspace
on that background thread but then schedule work to the UI thread
to ensure we correctly connect it to the right context (linked files,
shared projects, multitargeting, etc.) That code on the UI thread then
acquires the workspace lock, and we're seeing cases in the wild where
that lock acquisition is taking longer than we'd like. Although there
are deeper fixes we can do there, there's one trivial fix we can
make: don't schedule the work to the UI thread unless the file is in
at least two projects. Otherwise, we don't actually need to figure out
the context in the first place and it's just wasting time.
An entirely unscientific analysis of a handful of traces from users
hitting this, there weren't any cases where the file was actually
in more than one project, so this should have a nice improvement
overall.
Closes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2471561
/// Boolean flag to indicate if any <see cref="TextDocument"/> has been opened in the workspace.
54
56
/// </summary>
55
-
privatebool_anyDocumentOpened;
56
-
57
-
#endregion
57
+
/// <remarks>
58
+
/// This is written on the UI thread once it's been enabled, since the enablement can only happen there. It might be read on other threads in deciding to
59
+
/// do the work on the UI thread, but that's not a problem since <see cref="EnsureSuggestedActionsSourceProviderEnabled"/> is idempotent.
0 commit comments