12

I am running an interactive program that outputs about 10 MB [edit: probably closer to 100 MB actually] of ASCII text. The performance within emacs shell-mode (Aquamacs) is unacceptably slow, requiring hours to do this. I did execute buffer-disable-undo which speeds things up a bit, but it is still too slow.

I tried running the program with the buffer window hidden, but the program finished and when I reselected the buffer, I still have to wait hours for the output to spool.

Is there some command I can give emacs to make performance acceptable? I don't understand how it is even possible for shell-mode to be this slow: this is a 32 GB multicore machine with 64-bit modern multicore CPUs and SSD.

kdog
  • 1,583
  • 16
  • 28
  • 1
    Can you give details about your situation, most importantly, how exactly do you run this program? E.g. via `M-x compile` or in a `M-x shell` buffer or ...? – Stefan Nov 18 '14 at 14:12
  • I create a buffer with M-x shell. I do buffer-disable-undo in that buffer. I run lldb inside the buffer, and within lldb, run my program. It prints a lot as it's under development and I like to monitor the output; that is also why it should be interactive. This is a common normal way to develop under emacs - it's one of the advantages of shell-mode, you don't need separate log files all the time. It would work fine except that emacs is running ludicrously, laughably slowly. – kdog Nov 20 '14 at 04:12

2 Answers2

2

Set the variables comint-move-point-for-output and comint-scroll-show-maximum-output to nil. This prevents the buffer from continuously scrolling to the end of the output, which requires frequent redisplays.

Barmar
  • 741,623
  • 53
  • 500
  • 612
  • Haven't tried that yet, not sure if I should while the output is printing. However, the output is slow even when the buffer window does not show the end of output. For instance, right now the buffer is showing that I am at about line 2,000,000 and the output is spooling from about line 2,200,000 . All I can see is the scroll bar indication slowly moving up. Nothing is redisplaying. Although maybe the output is closer to 50MB than 10 MB for what that's worth. – kdog Nov 18 '14 at 03:10
  • In that case, I think you're doing the best you can do. It has to deal with the output so it can update the scroll bar and mode line percentage. I think there's a variable that says the maximum buffer size to display position and percentage in the mode line, but I can't remember what it is. – Barmar Nov 18 '14 at 03:18
  • 4
    Thanks. It's so frustrating to me that the emacs maintainers seem to spend all their time on idiotic features no one wants or needs, like web browsing, and the basic tools people use emacs for (programming) are buggy or flaky. There is still no decent C++ mode, for instance, just 50 different packages that are impossible to install and don't actually work (in my experience). If they want to put in a web browser, fine, but FIRST get the basic stuff working: code browsing, program development, etc. – kdog Nov 18 '14 at 03:23
  • 3
    Emacs is one of the oldest and most popular open-source projects. It's maintained by the users, the features that it has are the ones they want. – Barmar Nov 18 '14 at 03:24
  • 2
    Displaying continous output of multi-megabyte files is not a common activity. That's hardly "basic stuff". – Barmar Nov 18 '14 at 03:25
  • It's not just with megabyte output. In an emacs shell, ls'ing a directory with 1000 files is a VERY slow business (20 secs) unless the shell has just been started. It feels like as the shell ages it starts scrolling more and more slowly, even if you keep the buffer short by deleting stuff that's no longer interesting. – Silvio Levy Jul 14 '15 at 11:00
  • @SilvioLevy Do you have `comint-buffer-maximum-size` set? That requires it to keep counting the number of lines, and deleting old lines as new ones are added, which could slow it down. – Barmar Jul 14 '15 at 14:43
  • it's set but it's not relevant because I'm not doing buffer truncation -- my comint-output-filter-functions only contains (ansi-color-process-output comint-postoutput-scroll-to-bottom comint-watch-for-\ password-prompt) and not comint-truncate-buffer. Besides, the speed of output on a fresh shell contrasts with the dog-slowness for a shell that has had 1000s of lines of output (even if currently i've killed them all). That suggests the problem is that junk is getting stored and not being discarded. – Silvio Levy Jul 14 '15 at 18:38
1

Is your interactive program running within shell mode as a shell script?

Would it be possible to fork the shell process directly to a shell (not shell mode within emacs), then have emacs just load the results on completion?

Chris McMahan
  • 2,640
  • 1
  • 17
  • 10
  • 2
    See previous comment. I could always rewrite my program to work around emacs problems but I'd rather not. I'd expect that after 30 or 40 years of development, emacs would have a way to do reasonably fast shell mode. – kdog Nov 20 '14 at 04:14