Hacker News Reader

If the terminal is trying to update its display faster than the frame rate of your monitor, it's just wasting CPU cycles. A sensible terminal would rate-limit its updates and prevent the process from consuming all the CPU.

If your terminal can't draw a screen of text at 60fps on a semi-modern computer, it has a very inefficient renderer.

In my limited experience, rendering vector fonts is among the slowest parts of rendering text in a terminal. The difference between an xterm with a TrueType or OpenType font and an xterm with a PCF is noticeable.

This can make a huge difference. It can easily be worth the performance benefit to find a well-designed bitmap font[1].

I also highly recommend using urxvt[2], which not only has very fast rendering and support for a lot of modern features, it has a few settings you enable that specifically address the too-much-scrolling speed issue. From urxvt(1):

    jumpScroll: boolean
        [...] specify that jump scrolling should be used. When receiving
        lots of lines, urxvt will only scroll once a whole screen height
        of lines has been read, resulting in fewer updates while still
        displaying every received line [...]

    skipScroll: boolean
        [...] specify that skip scrolling should be used. When receiving
        lots of lines, urxvt will only scroll once in a while (around 60
        times per second), resulting in far fewer updates. This can result
        in urxvt not ever displaying some of the lines it receives [...]

These options can completely fix the scrolling lag problem.

[1] e.g. http://terminus-font.sourceforge.net/

[2] http://software.schmorp.de/pkg/rxvt-unicode.html

In case anyone is really interested in seeing some actual numbers. On my system, using the default system Monospace 11 font:

ls -lR / in urxvt terminal window - 16 s

vs

ls -lR / in gnome-terminal window - 3m17s

ls was run several times to make sure all information was cached. Same font, same window size, etc.

I prefer the standard IBM VGA font for its readability:

https://en.wikipedia.org/wiki/File:Codepage-437.png

The standard X terminal fonts ("fixed") are pretty good for other sizes, although I've fixed mine with a slashed zero:

https://en.wikipedia.org/wiki/Fixed_(typeface)

I use urxvt with Terminus. It's great.

...did you know that it supports rendering italics? Not particularly well, mind, especially with bitmap fonts, but it's there:

https://goo.gl/photos/pJtpccV8GX9QFkhn6

If you're using Linux, I'd advise you to use a fast terminal like Terminology; it even has GPU acceleration, but I doubt you'd need that. The only one that comes close on CPU-rendering speed is urxvt.

Pulling _all_ Enlightenment[1] dependencies just for a terminal emulator is a waste of time and space.

Why would I use that instead of rxvt ?

1: https://www.enlightenment.org/?p=about/terminology

Meh, waste is relative. I run KDE programs, Gnome programs, and a couple of other random hodgepodge things at my personal whimsy, and I'm still only using 2.5GB of the 8 on my system for non-cache work, and over a third of that is just Firefox. I've got 3.5GB literally sitting empty, according to free. I can't even fill the caches. Running another set of depedencies to get me a noticeably better terminal emulator would cost me virtually nothing real.

Of course if you're in difference circumstances the answer changes. But there's no particular virtue in using a worse terminal so that more of your RAM sits there with lots of 0s in it.

Tell that to the guy above who uses a Linux VM just to get a speedy terminal. :)

Well, fwiw my local Debian Jessie claimed terminology along with dependencies (that weren't already installed) would claim 24MB. Pretty steep for a terminal. I tried opening one each of Terminology and Sakura[s] -- and as far as I can tell, running:

  i=0;while true; do echo $i;i=$((i+1));done

is, if anything, slower in Terminology. Big caveat: I've just installed kernel 4.1.6 and while I've recompiled/installed the proprietary fglrx AMD driver, I'm not entirely convinced most OpenGL apps work as they should.

[s] http://www.pleyades.net/david/projects/sakura

This terminal emulator is also a file browser and media center, so you can save space by removing your old ones of those ;)

(tyls is ls with thumbnails, and tycat is like cat except that if you try and cat a movie file to stdout it will display a video player instead of raw bytes)

s/terminology/terminator/ then ..

I checked it out but couldn't figure out how to add my own color schemes? I'd preferably be able to use base16 flat https://chriskempson.github.io/base16/#flat however I can't even find a way to manually add color values.

> If you're using Linux, I'd advise you to use a fast terminal like Terminology

Egad, that pulls in a lot of dependencies! But yeah, it's blazingly, impressively fast.

Check out st[1] sometime. It's not as fast as either terminology or rxvt, but it's fast enough.

[1]http://st.suckless.org/

> it even has GPU acceleration, but I doubt you'd need that.

Ever accidentally cated a 4TB disc? It's… fun.

I dream of the day when we start making computers where a runaway process can't take away resources from the control interface. As in, you should always be able to kill a process, always be able to move and close a window and always be able to send a goddamn ctrl+c via a terminal. Otherwise we're in a classic priority inversion scenario - a lowly process can take away control from the user.

In many cases, you are able to send a control-c, but the process that is generating the output receives it, not the process, the terminal program, that is rendering the text. You'd have to send a signal to the terminal program, which may cause it to exit and not be what you want. And doing is often done with UI controls, like a close button/action on the window.

So it's not just priority inversion that is a potential problem, but also non-obvious layers of abstraction.

So you want BeOS?

Veteran gentoo user here. I've learned the joys of --quiet on many an old laptop for exactly this reason. There is no other process that I know of that is more likely to bottleneck a terminal. Accidentally cat some-binary-file? ctrl-c that sucker asap, hope you didn't have anything else important going on in there.

The standard Windows terminal is glacially slow for the same reason. The rendering of 80*24 characters seems to much for it if asked to display text at any speedy rate. Minimizing the window while the text is scrolling by can speed things up.

There is no getting away from it with the new "retina" screens. You will use TTF fonts, antialiasing, and most certainly some compositing underneath it all.

But I find that rxvt is quite speedy (in both Linux and OpenBSD) not to cause any noticeable lag when using "pretty fonts". Unlike OS X, where both Terminal and iTerm are still frustratingly slow at rendering text. Sometimes I'll fire up a Linux VM just to have a fast terminal and nothing else.

Why will you need TTF fonts and antialiasing? The higher the resolution, the less antialiasing you need.

With Retina screens, you need _absolutely enormous_ fonts, which is trivial for a vector font, but doesn't really seem to be done with bitmap fonts.

(IMO, you're right about antialiasing, though)

Text rendering has typically been the limiting factor since the early to mid 90's. Paging away is a good old trick. I usually run most things under screen, and so just switch to another screen. Obscuring the window is also often enough.

I've run into this also. I generally minimize the terminal (because that's where it would happen for me), but I have had to resort to moving to another desktop.

Strange. I often send 100MB+ dumps into terminal. Konsole from KDE or even my Java IDE has no problems to process it.

There's no problems with it, it's just slow.

Why?

gnome-terminal (based on libvte) will do frame dropping for rendering updates.

Unfortunately that means you're stuck using a terminal with the most brain dead shortcut keys in the world. Invariably I sit down at a coworker's keyboard, hit alt-F, and instead of skipping forward a word, I open the File menu.

What about the real old school approach and try XOFF?

Or, if you're not stuck on Linux, Control-O (or whatever you've set your terminal DISCARD character to).

For those that don't remember... That is ctrl-s. XON is ctrl-q.

That's my usual approach. After ctrl-s I usually use job control (ctrl-z) to suspend my misguided cat and kill % to kill it.