Performance: adding an `import` retriggers a long "Processing"

guibou commented 3 weeks ago

Your environment

Which OS do you use? Linux / NixOS Which version of GHC do you use and how did you install it? GHC 9.10.1, installed using nix/nixpkgs. How is your project built (alternative: link to the project)? A custom build system based on nix.

Which LSP client (editor/plugin) do you use? Neovim builtin lsp Which version of HLS do you use and how did you install it? 2.9.0.0 Have you configured HLS in any way (especially: a hie.yaml file)?

My hie.yaml contains:

cradle:
  bios:
    shell: "nix run .#haskell_hie_bios"

And the nix target haskell_hie_bios lists all the required build flags used by GHC to build one monolithic packages composed of 1089 modules. It also contains the listing of the 1089 modules, eg:

-XFoo
-XBar
-ipath/to/src
-ipath/to/src2
-ffoo
path/to/src/Module/Module.hs
path/to/src2/Module2/Module2.hs

Steps to reproduce

I don't know how to reproduce that outside of our large codebase, but what do I observe:

I've turned --debug --log /path/to/a/file.log
I start my editor (neovim, note that my collegues using vscode observes the same problem), load a file (for the example, I loaded a file which is at the end of the dependency tree, it contains a main function and no other module depends on that module).

After a bit of time, I can see:

2024-11-02T08:45:19.194755Z | Debug | Finished: C:GetHieAst:/home/guillaume/jinko/jinko/simwork/core-webservice/app/Local/Main.hs Took: 2m34s

In the log.

I can edit my file, do some change, that's super reactive. I can add function, hover for documentation, go to definition, everything is smooth and fast. Code action works fine, everything works great.
If I go to the top of the module, import section, I can add/remove symbols in the currently existing imported module, but if I add (or remove) an import statment, it starts Processing for a long time. For example, after adding import Data.Functor on top of my file, I can see Processing and Indexing (and actually, a few, sometime 2 or 3 Processing) and for a few seconds, HLS is not reactive anymore. Here is the message in the log:

2024-11-02T08:48:35.124980Z | Debug | Finished: C:GetHieAst:/home/guillaume/jinko/jinko/simwork/core-webservice/app/Local/Main.hs Took: 36.24s
2024-11-02T08:48:35.125044Z | Debug | Finished: C:GetHieAst:/home/guillaume/jinko/jinko/simwork/core-webservice/app/Local/Main.hs Took: 36.24s
2024-11-02T08:48:35.125125Z | Debug | Finished: C:GetHieAst:/home/guillaume/jinko/jinko/simwork/core-webservice/app/Local/Main.hs Took: 36.24s

(I'm surprised by the 3 lines of log. but note the 36s.). Note that there may be another problem with my setup or with HLS because 36s is a really long time, but the original problem is that I'm wondering why it is "re-processing" everything.

Expected behavior

Should not Processing for 40s when I had an import. I can understand that it may invalidate the build tree by adding an import, but this file being at the End of the build hierarchy, no module depends on it, so it is surprising.

Debug information

Sorry, I'm opening this issue without much details, in order to start tracking the problem. I'll try to investigate a bit more (especially, it looks like the issue is new at work, so I may be able to find which update triggered it.)

guibou commented 3 weeks ago

I've bisect our codebase and the problem appeared when upgrading to GHC 9.10 (same version of HLS in both cases).

Do you know how I can evaluate if:

HLS is doing something different because of the different GHC version, and this something different is slow
HLS is doing the same thing, but this is now slow with a different ghc version

The log with --debug roughly gives the same information, a Finished: C:GetHieAst, but without much more details.

fendor commented 3 weeks ago

Generally, it can be rather tricky to identify changes in behaviour across GHC versions... Maybe the open telemetry support we have is useful, see https://haskell-language-server.readthedocs.io/en/stable/contributing/contributing.html#tracing.

alexmccord commented 1 week ago

I ran into a similar problem when starting a new project, and I think this is caused by a mismatch in cabal and stack's build cache. If I modify my package.yaml (which seems to require restarting extension host to reload HLS) and run stack build without running cabal build, then HLS will get stuck at processing. If this is not the same exact issue, I can open a new one.

I have HLS 2.9.0.1, GHC 9.10.1, Stack 3.1.1, Cabal 3.12.1.0, all installed through GHCup. I have no hie.yaml in my project. This happens on Windows 11, and I am using the VSCode extension.

fendor commented 1 week ago

As cabal and stack don't share any build caches, this is almost certainly a different issue.

Please open another issue, and include the information obtained by following the steps here: https://github.com/haskell/vscode-haskell?tab=readme-ov-file#investigating-and-reporting-problems

guibou commented 1 week ago

@alexmccord note that it seems different, but I also observed infinite "Processing" since moving to GHC 9.10, but I had never really be able to understand / track / reproduce it. Most of the time, I restart the lsp, and/or clean the different caches and I'm good again. Sometime I think I had just let HLS run for hours (got bored, decided to leave for a hike) and when back, it was done. So may not be a "lock", but something really long.

Anyway, as @fendor said, maybe another (linked?) issue.

haskell / haskell-language-server