Massive performance regression from 1.8.0.0 to 1.9.0.0.

[htmue]

Your environment

macOS (Catalina/Intel i7, Ventura/Apple M2 Max), GHC 8.10.7, GHC 9.2.5, Stack projects, Sublime Text/LSP, HLS 1.9.0.0 with default config. GHC, HLS and Stack installed via ghcup.

Steps to reproduce

Open a project, wait for HLS startup to complete, edit code.

Expected behaviour

Instant feedback from HLS within split seconds, as with 1.8.0.0.

Actual behaviour

HLS 1.9.0.0 takes several seconds to respond to each keystroke, showing a progress message ("Processing 123/199") which hangs from time to time and starts over from the beginning multiple times while typing.

The bigger the project, the slower the response. Observed response times per keystroke go from 2-3 seconds with a 35 module project up to 10-20s (!) when there are a few hundred modules in the project.

The processing time seems to accumulate with each keystroke, even from trivial changes like adding whitespace. Typing and HLS feedback (diagnostics, autocompletions) go out of sync and sometimes one has to wait for a minute (!) or something like that before HLS settles down and feedback appears.

All of this makes 1.9.0.0 kind of unusable, especially for larger projects.

What was added to HLS that makes it so painfully slow? Is there a setting to disable this to get back the split second speed of 1.8.0.0?

[fendor]

Thank you for your bug report! This regression sneaked in, but the fix for it has already been merged and will be published with a point-release rather soon!
see #3458, #3452

Closing this, since it has already been reported, feel free to reopen if I misread

[htmue]

Just tried HLS 1.9.1.0. Unfortunately, the problem remains unresolved. Please reopen this issue, I don't have the permissions to do this.

[fendor]

@htmue Have you looked at #3458 to see whether it looks like your issue?

[htmue]

@fendor The processing time is in the same order of magnitude as reported in #3458, but I don't see a relation between the processing time and the number of files open, and the problem occurs with both GHC-8.10.7 and GHC-9.2.5.

According to the debug log, the processing taking place after each keystroke (textDocument/didChange notification) seems to be roughly the same as with HLS 1.8.0.0, only now it is orders of magnitude slower, like 20s instead of 10ms. A notable difference is that 1.8.0.0 checks many more files in the cache (GetModificationTime), for example 30 files checked by 1.8.0.0 vs. 3 files checked by 1.9.1.0 after the same edit in the same editor session. Does this help?

[htmue]

It turns out that SublimeLSP actually is able to support the workspace/didChangeWatchedFiles notification, only to do that it needs an extra package which provides the actual file watcher (LSP-file-watcher-chokidar). Once this is installed, the performance issue is gone, HLS is blazing fast again. This is also consistent with helix-editor/helix#5467 (comment).

[michaelpj]

Closing since it seems like a dupe