-
Notifications
You must be signed in to change notification settings - Fork 155
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
Very high CPU usage when editing fs file #975
Comments
I had this issue happening on non-vs code client (emacs) on M1 mac, which I thought was related to ARM arch but could be related to this, too: |
I think they are slightly different:
I just have the issue while typing. And once stopped the CPU calms down reasonable quick (seconds, not minutes). Though here it might be because of different CPU architectures? Or maybe different solution/project sizes? (Though razzmatazz/csharp-language-server seems to be smaller than FSAC (which I used for tests). But maybe different F# usage that caused different behaviour). Further tests for similarities:
|
On the main process. However, checking other files from the project WAS happening in the Background Service. However, due to some architectural changes in FCS, we don't need to do multi-process stuff anymore, so we moved back all the type checking to the main process. |
hm, interesting Using older Ionide ( So it seems the difference is: previously background checking/checking of related files didn't happen?... Another sign: Diagnostics after edit were just published for current file, but not for other files (in new FSAC version they are) |
There might have been bugs in stuff related to background service, but in principle, we always wanted to do checking (and yes, publishing diagnostics is the main user-visible result of it) of other files (that are below the current file in fsrpoj ) on edit. For what it's worth - I can reproduce the problem when I type really fast/keep the single key pressed for a while. Single character edits are not causing a huge spike (ofc, there's some CPU usage visible, but that's expected), which suggests that it's some kind of problem with cancellation (or maybe we should add some debouncing) |
Hey, @Booksbaum and @razzmatazz - could you try using FSAC from this branch - #977 ? |
It's way better -- but still way too high The good: The bad: The ugly: -> It's WAY better than before -- but still way too much CPU usage |
I mean, the F# compiler being fairly slow/performance intensive to use is not something I can fix it right now ;-) If the fix brings it back to usable state/similar utilization to previous versions, it sounds good to me. |
It's still only similar and really usable when no other files than the current one gets checked. (Which is ok for me) -> maybe as compromise/short-term-solution we could introduce a setting to disable checking other files? (here and for startup here (large spike when opening a new document for some seconds)). Then everyone can decide if diags for other files or less CPU is more important. And also depending on the size of the solution.
ohh...no alternative F# compiler up your sleeve? :D But I don't think it's just the F# compiler. Yes it's not exactly great performance wise -- but it's acceptable when it's just checking one file at a time. I guess multiple -> We should try to prevent multiple parallel checks Issue with solution above: Checking of current file gets delayed because some other file in project is still checking -> less responsive for user Then probably extract checking of other-than-current-working-file and only check them when there's no working-file-check active? Or just kill old |
I am not sure this is very much related to the discussion but lsp 3.17 now has “diagnostic pull model”, where the editor would pull diagnostics for the files it is displaying instead of the server doing the computation and pushing diagnostics proactively which I suppose is what is happening here. not sure about 3.17 support in vscode though |
VSCode seems to support pull diagnostics But this doesn't solve our problem as we still have/want to analyze all related files. -> pull diags are more about priority than load reduction |
didn't test the branch yet, because I couldn't build it on m1 mac due to fake breakage on macos/arm64 (?) but the latest fsac as of v0.56.2 fixes the performance/cpu hog issue for me |
With the new Ionide version (
7.0.0
) and new FSAC version (0.56.0
) (included in Ionide):Extreme CPU usage when editing code (up to 100% over all cores...) in fs file (-> inside a project, not Script files)
Repro steps:
In
FsAutoComplete
opensrc\FsAutoComplete.Core\TipFormatter.fs
, place cursor somewhere and just type whatever on the keyboard. CPU skyrockets and typing in VSCode becomes unresponsive.After not typing anything for a short while everything gets back to normal.
Location of high CPU usage is
CompilerServiceInterface.ParseAndCheckFileInProject
(->FSharpChecker.ParseAndCheckFileInProject
). It's expected to spend lot of time checking F# file with FCS, but not that much...Digging deeper:
Commands.CheckFileAndAllDependentFilesInAllProjects
not only checks current file, but also files after current F# file inside project (and files before when first open)-> matches higher usage when file is higher up in project file order; and when file is first opened
(though I think still higher (or with higher peaks?) than previous FSAC/Ionide version?)
dotnet --version
:6.0.302
The text was updated successfully, but these errors were encountered: