Freezes on argument completion with the R backend for company-mode

[lionel-]

I can consistently reproduce the following freeze:

• Open an R session.
• Write print(i = )

The freeze time seems to be influenced by the number of package loaded. Loading tidyverse and devtools results in much longer freezes.

Finding out what causes the freeze

Since debugging this sort of performance issues is not trivial, I'll document here how I found out the cause of the slowdown as this might be useful to users or developers. First I instrumented all ESS functions with the Emacs tracer:

(let ((fns (union (all-completions "ess" obarray)
                  (all-completions "inferior-ess" obarray))))
  (dolist (fn fns)
    (trace-function (intern fn))))

Ignoring all the irrelevant parts (such as ESS timers running periodically), I found the freeze likely occurred during ess-r-get-arg-help-string. More specifically, this part:

(ess-command ".ess_arg_help('intercept','print')\n")

It turns out that the freeze occurs at R level:

system.time(
    .ess_arg_help('intercept','print')
)
#>    user  system elapsed
#>   1.250   0.206   1.460

# The freeze is influenced by the number of loaded packages
loadNamespace("tidyverse")
loadNamespace("devtools")

system.time(
    .ess_arg_help('intercept','print')
)
#>    user  system elapsed
#>   8.329   2.048  10.423

Profiling suggests that a lot of time is spent in readRDS() via help().

Fixing the freeze

ess-r-get-arg-help-string is called by the meta method of the company-mode backend for R (implemented in ess-r-completion.el::company-R-args). The result of this function is displayed in the echo area when an argument is highlighted.

A few thoughts:

• Personally I had never noticed that these help strings were displayed in the echo area on completion. Probably because my eyes are focused on the drop-down menu that displays the completions. Since that feature is a "nice-to-have", and not very discoverable, I guess we can consider it non-critical.

• Caching would not really help, at least not for generics since available methods depend on the state of the session. Also the first access would still cause freezes.

• To implement this sort of contextual help with information stored on disk, synchronous requests are not appropriate. For this sort of things we need asynchronous routines. Unfortunately we don't have the tooling for this.

Since the contextual help is not critical nor discoverable, and since implementing correctly seems to be very difficult, I would suggest just removing the meta method from the company backend.

I have added an escape hatch until we sort this out: 44c0ddb71. Add (setq ess-r--no-company-meta t) to your init file to disable the feature causing the freezes.

[japhir]

This is likely related to the issue I've been having recently, where I call the help function on anything (e.g. ?mutate) and it hangs until I C-g a couple of times, then giving me an error message about something with readRDS() not working.

[lionel-]

@japhir The fix should be on MELPA soon. Can you let me know if it works for you please?

[lionel-]

Though it does sound like that's a different issue. The full error message would be helpful.

[japhir]

Ok thanks for getting back to me so quickly, I created a separate issue in #1075

[vspinu]

@lionel- maybe there is a way to optimize .ess_arg_help on R side. It's useful on company-show-doc-buffer

Agreed on disabling meta (the variable is now called ess-r--company-meta rather than ess-r--no-company-meta). But I wonder if we should just remove that part altogether. I think it's not very useful because eldoc kicks in and overwrites it anyhow. I have also never noticed it in the minibuffer area.