Improve performance of discovering the ghc version used by the project #2010
Comments
|
A simpler way to reproduce this may be to open a project that uses a cabal cradle, while replacing the echo Resolving dependencies...
sleep 60and observing that the HLS extension does not activate, and that it blocks other extensions from activating. |
jneira
added
type: bug
|
Hi, thanks for the detailed bug report. I agree that we should show some kind of feedback while hls is loading the cradle.
Afaics the haskell syntax extension is activated quite fast, without waiting for the full loading of the file, what other related (or not) extensions are being blocked? |
jneira
added
status: needs info
After further analysis, I think the problem may be that getting project GHC version can be really slow. Here's an example of it taking more than a minute (with the aforementioned repo): $ time /Users/rune/Library/Application\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-1.2.0-darwin --project-ghc-version
Found "/Users/rune/Obsidian/iohk/code/os-voltaire-fork/cardano-node/hie.yaml" for "/Users/rune/Obsidian/iohk/code/os-voltaire-fork/cardano-node/a"
--project-ghc-version 61.78s user 1.15s system 98% cpu 1:04.13 totalGiven that this takes so long,
It's not quite deterministic, unfortunately. I've experienced e.g. the smooth scroll extension not activating until HLS is done starting up. Yesterday I experienced VS Code being really slow to save a file ("File create action", I believe the title of the progress dialog was) while HLS was starting up. I think this is related to dependency resolution being slow for this repo, as it's the only repo I've worked with that has both really slow dependency resolution and makes the VS Code GUI hang on startup. |
jneira
removed
the
status: needs info
|
It appears the problem is that the cabal (which HLS runs on startup to find the project's GHC version) will take as long to finish as it takes cabal to resolve dependencies, which can be a very long time (e.g. in the case of the https://github.com/input-output-hk/cardano-node repo). |
|
Many thanks for the further investigation. It seems when the extension calls cabal/stack to "simply" determine what ghc version is being used by the project, no progress indicator is being emitted |
|
I agree that's a good idea. However, it would also be nice if we could issue a cabal command that finds the correct GHC version without requiring dependency resolution. As far as I can see, it's not necessary for cabal to resolve dependencies before reporting back which GHC version it's using. |
|
On my system, HLS runs the command below to find the GHC version, which takes 60 seconds for the Is there a reason we can't just execute the GHC script whose path is passed to cabal via the Running this takes a fraction of the time: |
good question, the code making that call is in hie-bios, to investigate (maybe @fendor remember that part faster) |
|
When we execute the wrapper, we need to get a ghc version. Whose ghc version should it report? It can't use the ghc on the path as it is wrong if |
|
thanks @fendor, so we need the real ghc before calling the wrapper (and getting it before is the reason the wrapper is so fast) |
|
The faster invocation i am able to conjure is |
|
@jneira Unfortunately that command is as slow as the current one: Perhaps it would make sense to limit this issue to implementing your suggested fix:
and leave the task of optimizing this command, in the cases where dependency resolution is slow, to a different issue? |
|
mmm or the other way around: create an issue in the vscode extension project about adding the progress notification and let this open until we get a way to reduce times:
in any case the improvement should come through a hie-bios change, as we are using it for get the ghc version |
Not sure if that needs improvement, as stack does virtually no solving, our current usage of |
|
@fendor what happens if the As far as I can see, stack should be able to return the GHC version without actually running GHC since the GHC version can be deduced statically from the snapshot.
That seems sensible. I will do that. |
That is true, but I don't think stack currently exposes suitable info at the moment.
Yes it is (directly before it), but I see how that might be annoying. |
jneira
changed the title
georgefst
changed the title
Does that actually help anything here? The implementation we've ended up with is that the build info is generated as a side-effect of We could propose that Cabal add a special command for getting the GHC version, which doesn't require solving for dependencies. But it doesn't seem worth it, since as soon as HLS is then loaded, the first thing we'd do is build the project anyway (although actually, if the first build is called from the wrapper, does that mean they use different build dirs?). |
|
@georgefst Exactly, that is one of the things that haskell/cabal#7500 was supposed to implement but it got slightly stalled.
Right, for completely cold builds, it makes no real difference except for generally slightly better start up times.
No, we still pass the correct build directory. |
Does it? It's not clear to me what repeated work would otherwise be performed. |
|
I think so, #2010 (comment) says that cabal resolves dependencies for running the |
|
But if the |
|
I would hope so but checking everything is up-to-date, but even then, it would be much better if obtaining the ghc version isn't performing the resolution because it increases the time to startup of HLS. So, the wrapper finds the ghc version and then launches the appropriate HLS version. If that takes long, the user has no immediate feedback and no IDE feature works. But if finding the GHC version and launching HLS is extremely quick, then HLS can provide certain IDE features immediately, such as |
Your environment
Output of
haskell-language-server --probe-toolsorhaskell-language-server-wrapper --probe-tools:haskell-language-server version: 1.2.0.0 (GHC: 8.10.4) (PATH: /Users/rune/Library/Application Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-1.2.0-darwin) (GIT hash: be2071e985cb417f984ab00a1aad76dee02d6d0b) Tool versions found on the $PATH cabal: 3.4.0.0 stack: 2.5.1 ghc: 8.10.4Which OS do you use:
MacOS
Which lsp-client do you use:
VS Code
Describe your project (alternative: link to the project):
https://github.com/input-output-hk/cardano-node
Contents of
hie.yaml:Steps to reproduce
Expected behaviour
Popup saying e.g. "Resolving dependencies..."
Actual behaviour
No extensions activate, stuff like saving a file hangs; all waiting for HLS to finish its cabal cradle operation (which is busy doing "Resolving dependencies...").
Include debug information
Execute in the root of your project the command
haskell-language-server --debug .and paste the logs here:Debug output:
Paste the logs from the lsp-client, e.g. for VS Code
LSP logs:
The text was updated successfully, but these errors were encountered: