10

When working with an iESS session of R and an R file open side-by-side, I noticed extremely slow performance when typing indetifiers. Typing braces and operators is fine, however, when an identifier is typed, there is very significant input lag (typed letters are appearing several second late). During this period, the the status of the iESS buffer flashes between run and no process. This happens most often when I am typing inside a function argument list and with a subordinate R process that consumes a sizeable chunk of memory (around 3G, a couple of big data frames and sparse matrices).

I have disabled eldoc-mode and company-mode, but ESS still seems to do something to the background R process synchronously.

What causes this? How can I profile ESS to find out how it spends time communicating with R?

I tried profiler-start and its friends, which show that Emacs spends 45% of its time in term-emulate-terminal (I ran htop in an ansi-term buffer to see the CPU usage of emacs and R) and 16% in the Automatic GC. That's hardly suspicious. I guess the time spent waiting for the subordinate process is considered idle time by the profiler.

Kristóf Marussy
  • 606
  • 4
  • 10
  • Notably, you're interested in strategies for solving similar problems yourself... not just another "gimme the code that fixes this!" type question. +1 – PythonNut Feb 26 '15 at 22:39
  • Yeah, I would be also interested in techniques for tracing/profiling process filters in general... According to my (very little) experience, they are a real pain to write and debug. :-) – Kristóf Marussy Feb 26 '15 at 22:43
  • 1
    I would just start `emacs -q` then evaluate just those part of your init file that sets up ESS. If the behavior is observed there I would file a bug report. If not, keep loading sections of your init file until you find the part responsible for your problem. Also, you may want to state which versions of Emacs and ESS you are running. – Ista Feb 27 '15 at 03:09
  • 1
    I think the "flashes between run and no process" is an indication of a bug (maybe something causes the process to die and be repeatedly re-started?). Have you reported this to the ESS maintainer(s)? One more thing: try `M-x load-library RET term.el RET` (i.e. load the uncompiled version of term.el) and then redo the profiling: it might give you a more detailed profile. – Stefan Apr 02 '15 at 12:49
  • Did you ever determine the source of the problem? My ESS buffer also hangs *all* the time. – Paul Brodersen Jan 13 '20 at 14:26
  • I suspect it's the completion system. For me, completing arguments of the function `plot` is especially painful. I think ESS actually queries R for the possible completion candidates, and there are a **lot** for `plot`. You might have better luch on the ESS help mailing list. – Tyler Sep 21 '20 at 19:02

2 Answers2

2

I know this is 5, almost 6, years late. The last response is from January of this year though.

There's been a recent development that might solve the issue for people in the future.

It turns out that the contextual help at the bottom in the minibuffer that appears when you're getting autocomplete is massively inefficient. This seems to be an isolated issue when company-mode is on. The current "fix" is a flag someone put into a very recent version of ESS.

You can enable it by setting (setq ess-r--no-company-meta t).

You'll still get completion from company-mode. The only difference is that the sometimes helpful, sometimes not, line in the minibuffer that will say plot(x, y, main="", etc., ...) will not appear.

See the discussion on GitHub.

MentatOfDune
  • 141
  • 4
1

Try turning off these:

(setq ess-use-flymake nil)
(setq ess-eval-visibly-p nil)

Flymake is on by default. Turning it off can speed things up. Also long lines in ess-eval-visibly-p can slow or stall emacs.