-
Notifications
You must be signed in to change notification settings - Fork 790
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
Visual Studio 2017 hangs, crashes when opening large F# solution #2793
Comments
Would you mind to take a gotMemory snapshot and share it? |
Do I understand correctly that no files are open? |
Yes I just open Visual Studio 2017 and open the solution. Not sure about sharing a dump, it's going to have file names and whatnot... but here are some screenshots in dotMemory when devenv.exe was around 1GB and climbing:
|
Wow o_O. There should be strictly one |
Can you show retaining paths for FSharpChecker? |
Oh wait, the number on the right is the number of objects under it. So there are only 2 FsharpChecker objects here (the number on the left). |
From how many projects do you have files opened? Can you open a single file from any project (and restart)? |
So this is all happening before any files are open in the editor. VS is hung on the Start Page, the Solution Explorer is empty. If it manages to load it (I have a smaller one with 61 projects that just barely loads, sometimes), right now one .fs file opens in the editor. Then it's kinda laggy and sometimes it manages to fall back on its feet and become usable, sometimes it crashes anyway. The diff from my last post was on this solution. The full 90 projects solution never makes it to that stage though. You get the dialog saying it's loading the projects, that dialog completes and disappears, then it just stays there and eventually crashes. |
Do you mind try https://drive.google.com/open?id=0B8HLQUKik9VtNFF1UEZNaElhZTg? I reduce project cache size from 200 to 5 in this build. First, open the dev command prompt and run
Then run my vsix. |
Using your VSIX, I get "The 'FSharpProjectPackage' package did not load correctly in VS". In ActivityLog.xml this seems relevant:
|
Ah, you have to disable strong validation checking. Another thought: can it be the case that your solution has circular project references? |
|
The solution doesn't have circular references. I thought this was impossible but I was curious so I wrote a program to verify it; it really doesn't. I'm seeing the same behavior using your VSIX. |
Well, on the smaller (61 projects) solution, with your VSIX it seems to more reliably open it and let me use it, after a very long loading time and going well into 2GB of RAM. But the full one still crashes as before. |
@vasily-kirichenko I think it did the same before, just not on load but after opening first file. |
@majocha no. It loads the project a file belongs to and all referenced projects. |
@vasily-kirichenko that's my concern too. I noticed that there's a call in ProjectSiteAndFiles that is O(2^n) where n is the number of projects in the Solution (with a worst case dependency graph). It's high on my list to investigate, but I imagine that memoising that function will significantly improve load time performance. My other concern is that Roslyn workspace setup is done async but it context switches back to the UI thread, locking everything up 😔 |
@vasily-kirichenko that was the case for some time but before my change that was a PR that queued all the projects and processed them at once after file open. So it's not entirely my fault :) |
The O(2^n) function I'm referring to is ProjectSitesAndFiles.getProjectOptionsForProjectSite |
I cannot reproduce it - all my solutions load quite fast. @asik a dotTrace snapshot would be very much appreciated. |
@vasily-kirichenko, this should help you reproduce the issue that @asik is seeing:
|
@cloudRoutine this thing should be cached https://github.com/Microsoft/visualfsharp/blob/master/vsintegration/src/FSharp.LanguageService/ProjectSitesAndFiles.fs#L111, like static let solutionService (serviceProvider: System.IServiceProvider) =
lazy (try Some (serviceProvider.GetService(typeof<SVsSolution>) :?> IVsSolution) with _ -> None) |
why can't we just pass it the |
Just wanted to point out that the call to |
@saul it's really cool you wrote that. It does repro the long loading time, however not the memory usage going out of control. But hopefully fixing the former would fix the latter. I looked at dotTrace and unfortunately it also has file names of all the projects and dlls, can't share that. But if it's certain ETW events you want I can run perfview, any particular command line? |
First PR addressing part of the problem is at #2802 |
@asik It would be really, really great if you could manufacture an entirely artificial huge solution that exhibits this problem. I know it might take a bit of work generating fake projects and code, but if we can capture the solution then we can put it in our automated test cases and ensure that we always scale to a solution of this size. This would be a hugely appreciated contribution if you could manage it. |
Good news! I can actually repro with @saul 's generated solution, on my work environment. I have no idea why in this environment the memory balloons out of control, whereas at home it doesn't. But maybe at home I'm not running the latest nightly. I'll retest when I get time. So anyway, dotTrace snapshot from VS slowly dying: |
@asik could you try #2801, grab vsix here https://drive.google.com/open?id=0B8HLQUKik9VtSlBtVTdfUHhYMjQ? |
@asik that is left over from Vasily's investigation. To fix it, create that file on your disk. |
That VSIX is not usable anyway, it's just POC where the problem is. I'm not gonna provide a fix. |
@saul @vasily-kirichenko @cloudRoutine I added the stress test projects generated by @saul directly to the repo in #2997. They are in tests\projects\stress Checking in the files directly is a bit brutal but we need to have at least a few project stress tests we can share, focus on and automate |
I believe I know how to fix this problem. We will have to change the shape of CompileOptions to no longer recursively specify the dependent projects but rather provide a list of projects options indexed by DLL name. I will work on a PR for this tomorrow |
WHile fixing #2793 I improved the diagnostics for some assertions and remove some exceptions that were happening on the startup path I also cleaned up the logic for BinFolderOfDefaultFSharpCompiler a little and take advantage of the fact that optdata/sigdata are gone to simplify some things.
WHile fixing dotnet#2793 I improved the diagnostics for some assertions and remove some exceptions that were happening on the startup path I also cleaned up the logic for BinFolderOfDefaultFSharpCompiler a little and take advantage of the fact that optdata/sigdata are gone to simplify some things.
We have a large (~90 projects) solution, mostly F#. In VS2015 it takes maybe 20-30 seconds to open and the memory usage is around 400MB. In VS2017, the IDE hangs after loading all the projects, memory usage quickly climbs in the 3GB range, and it can stay like that for several minutes before eventually crashing.
This seems related to F# as larger C# solutions don't present this problem.
This is closed-source so of course I cannot share the code, but I would be glad to provide any non-sensitive data to help diagnose this issue. I tried simply creating a new solution and adding our projects to it one by one. Around 60 projects the IDE became extremely slow and usually cannot open the solution anymore. If it manages to get past this loading phase, memory usage goes back to something normal. Then sometimes it becomes usable, sometimes it crashes anyway.
I just tried this again with VS Community 2017 (15.0.0+26228.12) and Visual F# Tools 15.4.1.17040401.
Here's a vmmap screenshot while it's hovering around 3GB:
The text was updated successfully, but these errors were encountered: