More Optimizations Made For Making GNOME/VTE Terminals Go Faster

[phoronix]

Phoronix: More Optimizations Made For Making GNOME/VTE Terminals Go Faster

Back in September GNOME developer Christian Hergert noted how Linux terminal emulators have the potential of being much faster based on his experiments. While at the time he didn't plan to pursue it further, in the weeks since he's been making enhancements to GNOME's VTE code that is used by GNOME Console and other apps...

https://www.phoronix.com/news/GNOME-VTE-Go-Faster

[pracedru]

Its nice. But terminals seem to run more than fast enough for me already.

[tildearrow]

"I still expect more work to be done around frame scheduling so that we can remove the ~40fps cap that predates reliable access to vblank information."

......what? Eliminating this cap only requires changing one or two lines of code... I remember doing this back in 2021.

[timofonic]

Any benchmarks already?

[Karl Napf]

Great that the terminal is faster now, but its speed was never an issue for me. Missing ligatures is what makes me go through the trouble of installing an extra terminal. I hope gnome will add that at some point.

[timofonic]

Great that the terminal is faster now, but its speed was never an issue for me. Missing ligatures is what makes me go through the trouble of installing an extra terminal. I hope gnome will add that at some point.

I agree.

Also, input and output latency is even more important for me.

[WereCatf]

If I do something in GNOME, I rather just fire up plain, old xterm than touch that GNOME Terminal-thing. It's just so god damn slow that I rather deal with xterm's deficiencies than use GNOME Terminal. Then again, I am absolutely spoiled silly by how good the Windows Terminal is -- it's just glorious.

[timofonic]

elduderino
Were you involved? What about input and output latency? Thanks anyway!

[elduderino]

......what? Eliminating this cap only requires changing one or two lines of code... I remember doing this back in 2021.

Sounds like you only reduced the timing delays in vtedefines.h then. What I've done (patch is on the issue tracker) is to drive the display updates from the frame clock (which itself is driven by vblank timings).

[elduderino]

elduderino
Were you involved? What about input and output latency? Thanks anyway!

It's hard to say without one of those dohickeys to actually test from screen presentation time. But I reduced a significant amount of overhead in the ring buffer code and completely got rid of display delays so they're driven by the next frame clock request (once that patch lands). The latency to your child process will look like:

* Compositor gets event from libinput
* Sends event to GTK application
* GTK application queues event until next frame is started
* Key event delivered to widget
* Vte writes the content immediately to the child process without delay (unless you somehow type thousands of keys per frame)
* echo will come from terminal line discipline in the kernel, PTY FD will signal POLLIN
* Read happens on next main loop iteration
* Data goes into scrollback

At this point it will end up in next frame. So *some* amount of the latency will be the roundtrip to the kernel through the line discipline and I expect that has reduced simply because the extra timeouts will go away (again, once the frameclock patch lands).

But to get things really low, you'd want to get rid of any delay introduced by the compositor or GTK's event controllers.