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

[guibou]

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]

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]

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]

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]

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]

@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.

[michaelpj]

I have also observed this. I wonder if the change to the imports is causing us to invalidate an excessive amount of state somehow?

[guibou]

I have also observed this. I wonder if the change to the imports is causing us to invalidate an excessive amount of state somehow?

Do you confirm that it only happen with GHC 9.10? Or did you observed it with another version of GHC and perhaps there are two issues: the invalidation (all ghc versions?) and GHC 9.10 performance regression somewhere else?

[guibou]

I've opened https://github.com/haskell/haskell-language-server/tree/repro_4443 which is a repro of this problem.

The test_invalidation cabal package at the root of the hls worktree contains two modules: MyLib and Lib2.

MyLib is kinda simple and takes 10s to compile:

{-# LANGUAGE TemplateHaskell #-}                                                              
module MyLib (i) where                                                                        
import Control.Concurrent (threadDelay)                                                       
import Language.Haskell.TH.Syntax                                                             
                                                                                              
-- | This code generates a super simple integer, but waits for 10s during                     
-- compilation                                                                                
i = $(do                                                                                      
  runIO (threadDelay 10000000)                                                                
  [e|5|])

It uses TemplateHaskell so that's a specificity. I would like to come with a simpler implementation which takes time to build, but I'm not too sure how to craft that (unless copy pasting a lot of code). I've tried to do type level computation (such as computing Fibonnaci at type level, but looks like GHC is smart enough to keep these type "lazy". Anyway.

The second module, Lib2 contains:

module Lib2 where                                                                             
                                                                                              
import MyLib                                                                                  
import Data.Functor ()                                                                        
                                                                                              
blurk = 20

With suffisant warnings set (-Wall, this module complains about missing signature, things like that.

Once HLS is fully loaded (after a minimum of 10s, when the warning are displayed), just remove the import Data.Functor () line and see how it takes 10s again.

This is perfectly reproducible here, with one gotcha (And I thought I was completly mad): I need to have both Lib2 and MyLib opened in my editor for the complete reevaluation to proceed. If only Lib2 is opened, nothing is happening.

By the way, I'm using neovim.

Next tasks:

• Test with vscode if the same behavior appears
• Test that with a GHC different than 9.10 in order to confirm that this is an issue with GHC 9.10 only.

[guibou]

Same problem with VScode.

Here is a "short" video showing the issue.

hls_invalidation-2024-12-31_22.49.55.mp4

[guibou]

(by the way, I'm using current HLS f09500b)