Terminal throughput comparison

[andmis]

I am considering switching to Emacs, and considering using emacs-libvterm as my terminal emulator. I ran some throughput tests and it looks like emacs-libvterm throughput is 3 or 4 times lower than in a normal terminal, and 2 times slower than in Neovim which also uses a libvterm-based terminal emulator.

I'm wondering whether this is expected, and/or whether there are things I should be configuring. For example, if I understand the meaning of vterm-timer-delay correctly, its default value of 0.1 seems way too high: doesn't this create a lower-bound of 100ms on the input latency? Interactive use of the terminal feels night-and-day different between 0.1 and 0.01 for this setting.

All tests are on a MacBook Pro M1 with up-to-date kitty and fish, running time find . in my home directory. My Emacs config is basically empty and the vterm Emacs package builds cleanly in all cases.

• Terminal Emacs with libvterm, vterm-timer-delay 0.1: 9.16 seconds.
• Terminal Emacs with libvterm, vterm-timer-delay 0.01: 12.58 seconds.
• Neovim: 7.11 seconds.
• Just my terminal: 3.13 seconds.

[andmis]

I am also experimenting with the emacs-mac port and get similar results there as with terminal Emacs.

[andmis]

Also, looks like the built-in terminal emulator in VS Code does this task in 6.60 seconds. Kind of surprising.

[brotzeit]

emacs-libvterm is very elisp heavy. There are low level functions that could be used to improve the speed, but since the package is not integrated into emacs and makes use of the module system this isn't possible. It's easier to contribute this way, but it's slow. If you are looking at thousands of lines of output, you shouldn't use emacs-libvterm.

Hopefully somebody implements a more performant libvterm mode directly into emacs, but I think for most users this package is fast enough in most use cases so I doubt this will happen(I've tried it some years ago, but it was too much for me).

[Sbozzolo]

Thanks for all the benchmarks and comments. One of the fundamental bottlenecks in emacs-libvterm is indeed the fact that is built as external module, with the main issue is that we have to convert C objects into Emacs ones, which has substantial overhead. There's room for improvement (for example, some copy operations could be avoided), but it would require some additional APIs on the Emacs side.

I'm wondering whether this is expected, and/or whether there are things I should be configuring. For example, if I understand the meaning of vterm-timer-delay correctly, its default value of 0.1 seems way too high: doesn't this create a lower-bound of 100ms on the input latency? Interactive use of the terminal feels night-and-day different between 0.1 and 0.01 for this setting.

That's correct. There's a tradeoff between responsiveness and speed. the smaller you set vterm-timer-delay, the more expensive large bursts of output become. The value of 0.1 is chosen as a good balance between normal usage and large outputs.

Hopefully somebody implements a more performant libvterm mode directly into emacs, but I think for most users this package is fast enough in most use cases so I doubt this will happen(I've tried it some years ago, but it was too much for me).

I concur with this statement. Ideally, we would want the fastest terminal that we can have, but I think that vterm is perfectly acceptable for several use cases (I haven't used any other terminal in years). With vterm, you give up rendering speed, but you gain speed in being able to interact with the terminal efficiently. A simple example is you can copy part of the output into another buffer with just a few keystrokes. At a higher level, vterm is just another Emacs buffer, so, if you use vterm, all you add a large number of features to your terminal experience.

[rudolf-adamkovic]

That's correct. There's a tradeoff between responsiveness and speed. the smaller you set vterm-timer-delay, the more expensive large bursts of output become. The value of 0.1 is chosen as a good balance between normal usage and large outputs.

What if VTerm started with a delay of zero and increased the delay automatically when large output starts coming through? After a while, it could then gradually decrease the delay back to zero.