`racer-eldoc' make type slow

[lynnux]

I use profiler-start' and profiler-report' to find the eldoc make typing slow. I disabled eldoc by (setq eldoc-documentation-function nil)

[Wilfred]

I'm afraid I'm going to need more details to investigate this. Can you give an example where racer-eldoc is too slow?

[lynnux]

Oh, I'm sorry that forgot to mention the environment, I'm on windows 8 64, compiled racer using nightly-msvc(release version). And I'm using auto-complete for completion. Maybe my hard disk is too old that cause racer running a little slow. But now I'm on another windows7 machine which running faster, still a little delay show of typing char. For example after std::, you can quickly and randomly type chars, that will reproduce. I also tried disable auto-complete mode, it remains. And I use the code adove: (setq eldoc-documentation-function nil), then it's OK.

[Wilfred]

Aha, Windows!

Starting processes on Windows is slow in Emacs. We really need to start a persistent racer process to make racer.el faster.

In the meantime, perhaps just disable eldoc? We could consider not enabling it for Windows users by default.

[politza]

I'm experiencing the same problem on Arch/Linux. Evaluating (racer-eldoc) often takes more than a second, making it pretty useless. I suspect my older hard-drive is partially responsible for this.

[Wilfred]

Would you mind running racer-debug after a slow eldoc query, and filing a bug on racer itself?

[politza]

I have a project, where I can deterministically reproduce two cases, in which calling racer on the command line with specific arguments takes 0.8s resp. 7s to complete.

[Kethku]

For what its worth I'm still encountering this issue. Everything was fine for a while but as my project got larger the slow down got nearly unbearable. To test I find that moving the cursor over variables in the scene file of https://github.com/Kethku/RustyRayTracer causes a multiple second delay. This makes rust in emacs unsable.

[aengusmcmillin]

Experiencing the same thing, any updates? It seems like it is happening even when I'm not typing, whenever I have racer-mode enabled, even if I am just moving around in the file, occasionally racer will start up and my entire emacs comes to a halt and never seems to finish. I noticed that in Task Manager a new subprocess was being added to my emacs called 'racer', and a corresponding 'Console Window Host'. When I close the 'racer' process emacs starts working again (and it closes the console window host process). This is what it looks like:

I am using spacemacs-base with only a few layers, but I was seeing a similar thing when doing a custom emacs configuration. I am on Windows 10 Pro.

It does seem eldoc related, mostly because racer just doesn't do anything otherwise, if I disable eldoc mode but run the racer-find-definition command the same thing happens.

For reference, in case it is useful, this is the output I got from racer-debug after closing the racer subprocess in the task manager.

The last racer command was:

$ cd d:/hearth/win32_platform/
$ export CARGO_HOME=d:/.cargo
$ export RUST_SRC_PATH=c:/Users/aengu/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust/src
$ c:/Users/aengu/.cargo/bin/racer.exe complete 43 16 d:/hearth/win32_platform/src/lib.rs c:/Users/aengu/AppData/Local/Temp/racer8480-CG

This command terminated with exit code 1.

stdout:

PREFIX 1426,1435,RUSTUSTST

stderr:

error: expected `where`, `{`, `(`, or `;` after struct name, found `impl`
 --> bogofile:2:1
  |
2 | impl Empty for RECT ;
  | ^^^^

The temporary file will have been deleted. You should be
able to reproduce the same output from racer with the
following command:

$ CARGO_HOME=d:/.cargo RUST_SRC_PATH=c:/Users/aengu/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust/src c:/Users/aengu/.cargo/bin/racer.exe complete 43 16 d:/hearth/win32_platform/src/lib.rs

Please report bugs on GitHub.

[aengusmcmillin]

Also, I just checked, and apparently when I'm hovering over something in the current file or in the std library and do racer-find-definition it works fine and very quickly, but if it is over a symbol it doesn't know about it keeps looking for it and doesn't give back my session. And so I think eldoc is just having it check racer all the time, and so it consistently fails to find definitions for things.

[kngwyu]

Hmm... So, should we set threshold to display eldoc? (e.g. If cursor doesn't move 0.5 sec then call racer)

[aengusmcmillin]

That might be a good way to go. I decided to just disable global eldoc mode which has mostly solved things. I also tried running the commands that were hanging individually on eshell with RUST_LOG=debug and I think my main problem is that I am using winapi. Just trying to look for one of the things I imported it started looking through tons and tons of stuff, so although it seemed like it was hanging, I think it was just taking forever searching. So I don't know if there is a great approach for this, ideally it just wouldn't be a blocking operation, but given that it currently is, I don't think I will be able to leave eldoc enabled at all.

[kngwyu]

I think my main problem is that I am using winapi. Just trying to look for one of the things I imported it started looking through tons and tons of stuff, so although it seemed like it was hanging

It's terrible... I'm going to tackle it after some bug fixes. Thanks.

[mgsloan]

Yeah, I recently moved off of spacemacs to a custom config, assuming that the slowness I was experiencing was due to throwing so much different stuff together in a bit of a kitchen sink. At least now I have insight about what configuration changes make my emacs go from responsive to super laggy. Unfortunately, it seems like I run into a lot of the same slowness with vanilla racer-mode + company-mode, even with a fairly small project.

This is not just for racer mode, I've also encountered things like this for most of the haskell integrations as well. It seems like having emacs start processes synchronously all the time when you move your cursor or type is not a very good way to have a responsive editor.

[mrcnski]

I can confirm that this is a problem for me for any medium-to-large-sized Rust buffer. It makes editing Rust code very unpleasant. I'm on OSX with an SSD and a recent Emacs.

[qdot]

I ran into this tonight, but managed to fix it using eldoc settings. Eldoc already has a way to do idle timing.

(defun racer-setup ()
 (setq eldoc-idle-delay 0.5))
(add-hook 'racer-mode-hook 'racer-setup)

This means eldoc won't start trying to render until half a second after your last input. You can increase this if that's still causing jank for you, or decrease it if you want it to show up after and the process spin-up doesn't take as long. I've found that going down to 0.2 still works ok for me.

You could also just lambda this into the racer-mode-hook if you wanted, the way I do it above with the discrete function is just personal preference.