UnusedPatternVariable diagnostic is very slow on big files
See original GitHub issueContinuation from #484.
When my project contains files like this (Utilities.elm) it makes my fans spin indefinitely, because a process running elm-language-client-vscode/server/out/index.js
runs 100% on one core.
I’m running the elm-language-client-vscode
master (https://github.com/elm-tooling/elm-language-client-vscode/commit/7532d7fc0caf9a6590b15f817272337f09bc0704).
I’ve checked that tree-sitter-elm can parse this file and it’s just fine.
Turning off the ElmLS Diagnostics
setting fixes the problem (but is unfortunate, obviously).
I have created a .cpuprofile, but I doubt it’s helpful. I think when I’m profiling a language server extension, I basically only profile the client part, but not the server part. This results in a profile that contains only native code, as 99% of the time its waiting for messages on sockets (this is my hypothesis). If you know any other way to profile this, I’d be happy to try it.
I would love input in how to further test this issue. Can anyone else reproduce this issue?
Maybe it’s related to file size (and it’s just running reeeeally long), as the file is almost 33kLOC, but it has never run to completion, even after hours. This is incorrect! It finishes after ~10 minutes. It seems I got the impression it never finishes, because the process gets restarted once I save any other Elm file?
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (8 by maintainers)
Yeah, there’s just not a fast way of doing it like this. I was thinking about switching unused diagnostics into the type checker, which would use references from type inference to determine what is unused.
Ok. I’ve done some delta debugging.
I’ve enabled the ElmLS Diagnostics again, and systematically turned settings in
elm-analyse.json
on and off.With these settings, there’s no issue:
However, these settings do make my fans spin for >2 minutes (at least. I interrupted it):
So it seems like
UnusedPatternVariable
is the culprit.