Skip to content
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

Massive performance regression from 1.8.0.0 to 1.9.0.0. #3476

Closed
htmue opened this issue Feb 2, 2023 · 6 comments
Closed

Massive performance regression from 1.8.0.0 to 1.9.0.0. #3476

htmue opened this issue Feb 2, 2023 · 6 comments
Labels
component: ghcide performance Issues about memory consumption, responsiveness, etc. type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..

Comments

@htmue
Copy link

htmue commented Feb 2, 2023

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?

@htmue htmue added status: needs triage type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc.. labels Feb 2, 2023
@fendor
Copy link
Collaborator

fendor commented Feb 3, 2023

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

@fendor fendor closed this as completed Feb 3, 2023
@htmue
Copy link
Author

htmue commented Feb 16, 2023

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
Copy link
Collaborator

fendor commented Feb 16, 2023

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

@fendor fendor reopened this Feb 16, 2023
@fendor fendor added component: ghcide performance Issues about memory consumption, responsiveness, etc. and removed status: needs triage labels Feb 22, 2023
@htmue
Copy link
Author

htmue commented Feb 22, 2023

@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
Copy link
Author

htmue commented Mar 13, 2023

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
Copy link
Collaborator

Closing since it seems like a dupe

@michaelpj michaelpj closed this as not planned Won't fix, can't repro, duplicate, stale Jan 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ghcide performance Issues about memory consumption, responsiveness, etc. type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
Projects
None yet
Development

No branches or pull requests

3 participants