Slow error checking

[LukaHorvat]

Sorry to raise this issue again but the error checking has been exceeding slow (I believe since the last major version but I can't be sure). The time to check for errors is roughly the same as running ghc-mod check <path> however it takes the same time running it again.

Manually running ghc-modi and doing check <path> takes a bit of time but after changing the file and running it again it's very fast.

What can I do to help with debugging this?

[LukaHorvat]

Further info: When I save, 3 ghc-mod processes start up and when the errors are delivered they disappear.

[lierdakil]

Checking always used non-interactive mode, except for onChange events, primarily to a) avoid crashing interactive process and b) allow for type/info queries even if check is in progress. There also were some problems with interactive check in the past, but those are (mostly) resolved upstream by now. I've released v2.1.0 which adds an option to change that, which is enabled by default as an experiment. In case of related issues, I will reset it to disabled.

[lierdakil]

Note: lint still spawns an additional process, since it's always reasonably fast and it seems better run it in parallel then to wait for when check is done (ghc-modi is synchronous, so no other way around that)

[LukaHorvat]

Well, this did seem to help (I'd say maybe even twice as fast now) but the time went from ~10 seconds to ~5 seconds. Here' check this out.

Here's me manually checking the file with ghc-modi:

The error is almost instant.

Now here's the same scenario with automatic error checking with haskell-ghc-mod enabled:

I hope you can see what I'm talking about. The second example takes a LOT longer.

[lierdakil]

Try checking debug log to see what could possibly go wrong here (Debug option in haskell-ghc-mod settings, then see dev. console). Also bear in mind that checking files with errors is always faster than checking files with no errors (since GHC fails with the first type of error it finds for obvious reasons).

It's really hard to time gif images, but I ran some tests on pandoc-citeproc (a reasonably large project), and got the following results for checking the library entrypoint (which imports almost the whole project):

• In Atom:
  • First check takes about 4.5 seconds with no errors and about 3.8 seconds with errors
  • Subsequent checks take about 3.7 seconds with no errors and 3.5 seconds with errors
• In ghc-modi
  • Two "cold" checks take about 7.5-8 seconds with or without errors (but this also counts startup time)

In conclusion, one check takes about 4 seconds regardless if it's in Atom or in ghc-mod directly, and fluctuations are within margin of error. Don't see a major difference there, so this is either project-specific, or there is some factor you didn't account for in your testing, I reckon.

Also worth noting, that when you save a file in Atom (even if it's not modified since last save), it's modtime gets updated, and ghc-mod has to reload and recheck it, instead of showing previous check results. I don't think it's an issue.

Lastly, make sure you're comparing the same version of ghc-mod, there can be major differences in performance between versions (which depends not only ghc-mod version, but GHC version as well)