-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
[Responsiveness] Roslyn initialization is forced onto the UI thread, forcing the project system to synchronize initialize it (6.9% of solution open) #55297
[Responsiveness] Roslyn initialization is forced onto the UI thread, forcing the project system to synchronize initialize it (6.9% of solution open) #55297
Comments
We cannot do this, until we've fixed the race in dotnet/project-system#485. |
This is now blocked by #15871 |
Taking this, since @jasonmalinowski's work will likely not be ready before @davkean is out. |
Moving to 15.7, since this work is risky and we'll try to tackle this early in 15.7. |
Everything but creation is thread-safe and thread-agnostic. |
We have done this for population and dispose (dotnet/project-system#4229), and just waiting on creation. We are blocked on Roslyn making a change around this. |
Dispose isn't free-threaded, so backed that out: dotnet/project-system#4234
|
We still have two instances of switching to the UI thread in |
@drewnoakes Is the work solely on our side, or do we need something further from Roslyn to eliminate those last two places we switch to the UI thread? |
Roslyn needs work.
|
Filed #51016 to track the Roslyn side of this work. |
dotnet/project-system#6953 removes one of the two UI switches. |
#51138 is the Roslyn-side of the other UI switch. |
The roslyn side of this is complete. You can go ahead with this @drewnoakes |
Thanks @CyrusNajmabadi. I'll pick this up once an updated version of the |
This comment has been minimized.
This comment has been minimized.
Fixes #353 Roslyn recently implemented a free-threaded version of this API, meaning we no longer need to switch to the UI thread before calling it. This commit bumps the package version, removes the thread switch and calls the new API.
Fixes #353 Roslyn recently implemented a free-threaded version of this API, meaning we no longer need to switch to the UI thread before calling it. This commit bumps the package version, removes the thread switch and calls the new API.
Fixes #353 Roslyn recently implemented a free-threaded version of this API, meaning we no longer need to switch to the UI thread before calling it. This commit bumps the package version, removes the thread switch and calls the new API.
Re-opening. Roslyn made changes to support this, but it introduced DDRIT failures. |
Fixes: .NET Project System's side of https://github.com/dotnet/project-system/issues/353. Roslyn already immediately switches to the UI thread CreateProjectContextAsync, so this should be a no-op. However, this enables the above bug to be moved over to Roslyn and for them to remove the UI thread dependency in the future.
Fixes: .NET Project System's side of https://github.com/dotnet/project-system/issues/353. Roslyn already immediately switches to the UI thread CreateProjectContextAsync, so this should be a no-op. However, this enables the above bug to be moved over to Roslyn and for them to remove the UI thread dependency in the future.
That seems reasonable. Though i think @jasonmalinowski will need to be pulled on this. He has the most context on why parts of our PS impl are UI thread affinitized. I have no doubt we can get (almost) everything off the UI thread, but he'll be the best at just knowing the places that are currently problematic. |
I've moved it over, the project system change has been merged in. |
@CyrusNajmabadi @davkean I'm confused for what the remaining asks are here for this bug. It looks like @drewnoakes reactivated it when @CyrusNajmabadi's fix had DDRIT failures, but it seems all the changes have now gone in? |
Project System removed their switch but this path still immediately switches to the UI thread, blocking it and preventing other things from progressing and overlapping. |
Yes. The only work we did was to enable this to be called asynchronously from any thread. We didn't do anything on our end to make things better on the UI thread. |
@drewnoakes I think we can close this at this point, or do you still have a UI thread switch before calling into Roslyn somewhere? |
@jasonmalinowski This is representing the time Roslyn spends on the UI thread, last I saw in some traces, this was up to 30%. This isn't resolved. |
@davkean Can you share the trace then? |
@davkean Also to be clear I'm using this bug to track the original request which was making the project initialization path moved off the UI thread which is now as far as it can go without having shell APIs changed; if there's other paths that aren't that, we should have bugs for those, but let's have new bugs for those. |
@jasonmalinowski I filed the original bug, and its always been about Roslyn chewing the UI thread. All Orchard Core traces are showing this. Here's from yesterday's build from a cached load: If you believe that Roslyn are unable to address these, then dupe these against the shell bugs we've filed. Looking at the trace, |
@davkean Alright, we can take a look at fixing that, thanks for the info! |
(and indeed that's a different stack than I've seen be expensive before...) |
IWorkspaceProjectContextFactory.CreateProjectContextAsync is forced on the UI thread via Roslyn during solution load. UI thread is scarce resource during solution load and this means that Roslyn is prevented from being initialized until each project synchronously blocks on it in PrioritizedOnAfterOpenProject.
The project system would like to overlap this initialization so that we can make use of as many cores as possible during load.
The text was updated successfully, but these errors were encountered: