flycheck-haskell is very slow when stack.yaml is not pressent #98
Comments
|
@turboMaCk Hi, thanks for the report and conducted investigation. However, I cannot reproduce the slowdown - I've created a simple cabal project with a To help the investigation, can you please conduct some emacs profiling to show what's being slow for you? For example:
|
|
Well I just found some time and wanted to try it again (previously I solved it by uninstalling stack). I can no longer reprouce it but before it seemed like unavoidable issue no matter what I tried. Since then I did both update system and emacs packages and did other changes so likely something of that unknowingly to me solved the issue. I'm using nixos which is quite different compare to most of linux distributions, there might even been some fix for some stack issue on nixos. Since this is irreproducible now I'm closing the issue. |
|
I still have a problems with this from time to time. This is a profile report. It might be something specific to my config. I would apprichiate any advice but if you think this is not related to flycheck-haskell feel free to just close this issue. |
|
@turboMaCk Thanks for coming back. One question I didn't manage to ask in this thread yet but which strikes me as a crucial one - do you observe Unfortunately, the profiler report doesn't point no anything obvious - there's 30% spent on GC (probably flycheck wasn't directly involved) and 45% spent on a command invoked via Alas, report doesn't show what was actually invoked - there's ssome compiled lambda AFAIK and it's not clear, even if it was a flycheck-related function, what it was. That being said, I think I'm going to go ahead and add a customization option to disable checking for stack altogether - if you don't want |
|
To be honest looking at that trace I also start to think it's not realy flycheck-haskell related. I have no idea what it can be but perhaps if I find a time and try to reduce my config to some minimal reproducible example it would become more obvious. If you want to add that option I definitely have no objections but it really depends on your judgement and not mine. if you feel like it has no other use than to solve this issue I would consider just closing this until I'm able to show how it is related and that such change can indeed mitigate the issue. My (design) guts tell me there is no reason to introduce and API which might be useful. The only thing I don't understand is why I don't observe this issue when I turn flycheck off. |
|
I am having a similar issue. I am using Manjaro with GNU Emacs 26.3 (as a daemon). The profiling report is similar to the one that @turboMaCk gets (it doesn't point to anything obvious) and I can confirm that the Even if I uninstall the |
|
btw I'm also running Emacs as a daemon myself even though I don't see how it can be related. |
|
Have you found any solution @mx-psi ? I've solved it by uninstalling stack from my system last year but now I need to have stack installed because of work and this starts driving me mad when ever I work on project that doesn't use stack. |
|
No, @turboMaCk, I did not manage to make any progress unfortunately :( |
|
Seeing this too |
Hello 👋
I have huge performance issues with using flycheck-haskell on any project that doesn't use stack as a build tool. Even basic text editing is incredibly slow while working on those files. The workaround is to
$ touch stack.yamlwhich fixes the issue (no matter that file is empty). Another possible workaround is to uninstallstackcompletely from the system. It seems to me that something has to be recursively looking for nearest stack.yaml file while blocking the ui.Tested on NixOS using GNU Emacs 25.3.1 and GNU Emacs 26.1 with the latest version of flycheck-haskell.
The text was updated successfully, but these errors were encountered: