haskell-vim-now
haskell-vim-now copied to clipboard
very slow type (,ht) and linter (,hl)
Am I the only one experiencing very slow ,ht and ,hl?
With Haskell-vim-now I see a lot of gcc/clang compiling in the background every time I hit ,ht or ,hl. With large projects or when using heavy frameworks like Yesod the waiting time is really holding up the work flow.
I'm using Atom as a benchmark, I think they are using ghc-mod and/or hdevtools in the background and it's very snappy.
Remark: I noticed that Haskell-vim-now actually didn't install hdevtools although it is listed as a "necessary support binary".
Haskell Vim Now uses ghc-mod internally, so I'm curious how Atom goes faster in that regard. Can you get a rough measurement of the two and tell me the speed difference?
Also the readme is out of date when it mentions hdevtools. For a time ghc-mod was broken and I switched to hdevtools but ghc-mod got fixed and I was able to switch back.
It Atom these operations run in < 1/2s Emacs seems even faster than Atom. In vim the same takes about 7s.
See the attached gifs.
Atom:
Emacs:
Vim:

Thanks for the illustrations. That's pretty bad performance, let's figure it out.
HVN uses the ghc-mod in ~/.local/bin, which ghc-mod do the others use? Maybe there is a speed difference in different versions of ghc-mod.
I'm running ghc-8.0.1 in all cases.
To dig a bit deeper I ran lsof -r1 -u myname > out before opening Vim and Atom. With that output it's difficult to understand what exactly these are doing, but I can say this:
- both Vim and Atom use the same .local/bin/ghc-mod
- Differently to Vim, Atom very heavily interacts with ghc-mod when it opens the .hs file. Thereafter, the interactions with ghc-mod look very similar: Commands are sent (pipe) to the one ghc-mod process.
- Neither uses hdevtools
Maybe this issue has something to do with it.