For convenience (at least so far) I am running my program that produces a lot of debug output in Emacs shell.

However I have a problem: Sometimes (not all the time) moving the cursor (up, down, left, right) is terribly slow. I mean seconds until the cursor moves.

I'm using PuTTY to connect via SSH in text mode to a SLES12 SP5 Linux machine (i.e. Emacs 24.3) that runs in VMware.

Once when the cursor did not move for seconds, I noticed in another terminal (that would react at normal speed) that the Emacs process (emacs-gtk) was at 99% CPU for a long time. So I disabled line-number-mode, but that didn't help. Next I disabled font-lock-mode, but that also did not help.

The size of the *shell* buffer is about 7.9MB, the system has 290MB free, 265MB buffers, and 910MB cached, so memory should not be the problem.

I'm somewhat clueless. What could be the problem, and how can I fix it?

I did an ltrace -p <pid_of emacs-gtk and I saw that a memcmp with the same four(!) parameters (and a small size like 9) is called all the time while the cursor refuses to move.

Line lengths

As I had been asked about the length of the lines: The lines are not extremely long; I'd say most are shorter than 160 characters, and none should exceed 300 characters. I know that Emacs can be very slow for lines with thousands of characters, but that was not the case.

Moving direction

When trying to reproduce, the effect was not as extreme as it was before, but I noticed that moving the cursor up one line while at the beginning of a line seems significantly slower than moving down the cursor to the next line.

I even had re-enabled line-number-mode and font-lock-mode. This test had a buffer size of roughly 8.9MB with 116000 lines, making an average line length of about 77 characters.

  • My guess is that the problem is the sheer volume of output. Are you still experiencing the slowness after the process has exited and the final output has been inserted into the shell buffer? Or are the performance problems only happening while the program is running and generating new output?
    – phils
    Commented Sep 23, 2022 at 12:38
  • @phils Good question, but actually I don't remember for sure. My guess is that both is true: The program in test is basically an endless loop, but it does not output messages all the time; only when specific events are processed. So I started to inspect the output while the process might add new lines at the end.
    – U. Windl
    Commented Sep 24, 2022 at 20:52
  • Certainly any process which is both ongoing and "very chatty" is liable to slow Emacs down. Ultimately a shell/terminal written in elisp simply isn't (remotely) as efficient as a stand-alone terminal written in some compiled language, so if there's a lot of text to process, there's a lot of overheads, and in the end there are thresholds beyond which you're better off using something else. I suspect stevoooo's suggestion of using the libvterm integration is indeed the best inside-Emacs option, if you can get it working; otherwise I would just use an external terminal.
    – phils
    Commented Sep 25, 2022 at 1:45
  • 1
    That said, you can use the in-built profiler to try to get a picture of where most of the time is being spent. See C-h i g (elisp)Profiling to learn about that.
    – phils
    Commented Sep 25, 2022 at 1:48

1 Answer 1


It sounds as though you may be suffering from the infamous "Emacs is very slow with long lines" issue, for which you can see some previous answers at How do I prevent extremely long lines making Emacs slow?. Emacs 24 is pretty old now, but that does say that "so-long" mode is available on ELPA and this may help with your issue.

In my experience however, the real solution for slow shells or terminals in Emacs is emacs-libvterm, which being based on a native C library is exceptionally fast, provides excellent terminal support, and doesn't suffer from issues with large outputs. The downside of this is that Emacs 25.1 or later with module support is required. I would strongly urge you to get a more recent Emacs and check it out though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.