Slow response when a simple number (e.g., 5) is trying to be resolved interactively

[chendsh]

I am trying a little piece of haskell code like this in a file (test.hs) using haskell-mode.

infixr 5 :-: 
data List a = Empty | a :-: (List a) deriving (Show, Read, Eq, Ord)

But each time when I moved the cursor to 5 just after infixr, emacs became very slow and the CPU usage went high. Looks like haskell-mode was trying to resolve this 5 by contacting GHC interactively and finally displayed in minibuffer something like this;

5 :: Num p => p

Here is the cpu profile of emacs. (sometimes it reaches 89% etc., not only 57% shown here)

- haskell-process-filter                                          367  57%
 - haskell-process-collect                                        367  57%
  - haskell-command-exec-complete                                 367  57%
   - #<compiled 0x361adc1>                                        367  57%
    - #<compiled 0x2ecb8fd>                                       367  57%
     - eldoc-print-current-symbol-info                            367  57%
      - eldoc-message                                             367  57%
       - eldoc-minibuffer-message                                 367  57%
        - apply                                                   367  57%
         + message                                                132  20%

I am using emacs 26.2 for windows and installed haskell-mode-20190417.309 from melpa.

And here is the configuration for it.

;; haskell-mode
(autoload 'haskell-mode "haskell-mode")
(autoload 'haskell-cabal "haskell-cabal")
(add-to-list 'auto-mode-alist '("\\.hs$" . haskell-mode))
;;(add-to-list 'interpreter-mode-alist '("runghc" . haskell-mode))
;;(add-to-list 'interpreter-mode-alist '("runhaskell" . haskell-mode))
;;;(setq haskell-program-name "ghci")
(add-hook 'haskell-mode-hook 'interactive-haskell-mode)

And this is the only external package I installed.

ghc version; The Glorious Glasgow Haskell Compilation System, version 8.6.3

[jakzale]

Had a similar issue with Emacs on Windows. I was able to resolve the issue by disabling eldoc-mode in haskell-mode.

As you can see in your profile there is something horribly wrong happening in Emacs when running eldoc-minibuffer-message. I am not sure if this is not a bug in Emacs itself, but haskell-mode is using eldoc to display the type of the symbol at point in the minibuffer.

You can disable eldoc by adding the following lines to your configuration:

;; disable eldoc in haskell-mode
(add-hook 'haskell-mode-hook #'(lambda () (eldoc-mode -1))

[krizmak]

Same problem with Emacs on Windows, same solution that @jakzale wrote. Thank you for the hint!

What I can see is that eldoc works properly before I load the file to process (C-c C-l), but font faces are plain. After I load the file to the process the font faces of eldoc in the minibuffer changes to have more colors and it slows down extremely.

I have no similar problem with Emacs on Linux.

[purcell]

Which GHC versions / builds for Windows are y'all using?

[jakzale]

• GNU Emacs 26.3
• ghc 8.6.5 (installed by stack)
• Windows 10, Version 2004 (19041.153)

[purcell]

Thanks. I don't have access to a Windows machine to try this on, and I'm not sure if any of the other repo contributors are following these issues. It might help gathering information to use profiler-start/profiler-report either side of triggering the slow code, but that sometimes does not show up delays due to async communication with processes. The other thing you could try is to set debug-on-quit and then hit C-g while Emacs is unresponsive: this (usually) produces a backtrace which can contain useful information.