7 ms·

I was 'shocked' to discover a few months back that, when I made the horrible mistake of starting a job that wasn't easily Ctrl+C killable and dumped a lot of ou

I was 'shocked' to discover a few months back that, when I made the horrible mistake of starting a job that wasn't easily Ctrl+C killable and dumped a lot of output to the screen, I was better off paging to antoher desktop and waiting for it to go away, because the limiting factor to the data-dump wasn't the bandwidth between my machine and the remote, nor the buffer size of the terminal, socket, or whatever else in between, but the speed at which my terminal rendered text, which was rendered moot by being on another desktop where the text didn't need to be rendered and the xterm (or also iterm) session could page-past that text without disturbing my desktop display. It makes a lot of sense. Much goes into your text rendering beyond what was necessary in your VT100. Every screen I see is anti-aliased, horizontally and vertically aligned, with 'lines' of text that can wrap or be colored or myriad other things according to the byzantine and arcane standards of the escape codes and ones that have come after. Re-drawing even a fairly large amount of text is fairly non-trivial cpu and gpu time. I found I got way better performance and less lag from my machine if I disabled the alpha transparency on my terminal windows. Processing power is very high, but still far from unlimited.

Aissen 11y ago
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.
- hyyypr 11y ago
  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 https://www.enlightenment.org/?p=about/terminology
  - Flow 11y ago
    Tell that to the guy above who uses a Linux VM just to get a speedy terminal. :)
    - e12e 11y ago
      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 http://www.pleyades.net/david/projects/sakura
  - Shish2k 11y ago
    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)
  - fit2rule 11y ago
    s/terminology/terminator/ then ..
  - jerf 11y ago
    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.
- creshal 11y ago
  > it even has GPU acceleration, but I doubt you'd need that. Ever accidentally cated a 4TB disc? It's… fun.
- hultner 11y ago
  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 https://chriskempson.github.io/base16/#flat however I can't even find a way to manually add color values.
- wtbob 11y ago
  > 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/ http://st.suckless.org/
jkot 11y ago
Strange. I often send 100MB+ dumps into terminal. Konsole from KDE or even my Java IDE has no problems to process it.
- creshal 11y ago
  There's no problems with it, it's just slow.
- philtar 11y ago
  Why?
vidarh 11y ago
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.
hyperion2010 11y ago
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.
delan 11y ago
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.
- pdkl95 11y ago
  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/ http://terminus-font.sourceforge.net/ [2] http://software.schmorp.de/pkg/rxvt-unicode.html http://software.schmorp.de/pkg/rxvt-unicode.html
  - david-given 11y ago
    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 https://goo.gl/photos/pJtpccV8GX9QFkhn6
  - userbinator 11y ago
    I prefer the standard IBM VGA font for its readability: https://en.wikipedia.org/wiki/File:Codepage-437.png 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) https://en.wikipedia.org/wiki/Fixed_(typeface)
bnastic 11y ago
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.
- 4ad 11y ago
  Why will you need TTF fonts and antialiasing? The higher the resolution, the less antialiasing you need.
  - apenguin 11y ago
    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)
joosters 11y ago
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.
anon4 11y ago
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.
- thwarted 11y ago
  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.
- cuckcuckspruce 11y ago
  So you want BeOS?
arethuza 11y ago
What about the real old school approach and try XOFF?
- ansible 11y ago
  For those that don't remember... That is ctrl-s. XON is ctrl-q.
  - sevensor 11y ago
    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.
- kps 11y ago
  Or, if you're not stuck on Linux, Control-O (or whatever you've set your terminal DISCARD character to).
Steltek 11y ago
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.
AndrewStephens 11y ago
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.
a3n 11y ago
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.

Aissen 11y ago

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.

hyyypr 11y ago
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 https://www.enlightenment.org/?p=about/terminology
- Flow 11y ago
  Tell that to the guy above who uses a Linux VM just to get a speedy terminal. :)
  - e12e 11y ago
    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 http://www.pleyades.net/david/projects/sakura
- Shish2k 11y ago
  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)
- fit2rule 11y ago
  s/terminology/terminator/ then ..
- jerf 11y ago
  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.
creshal 11y ago
> it even has GPU acceleration, but I doubt you'd need that. Ever accidentally cated a 4TB disc? It's… fun.
hultner 11y ago
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 https://chriskempson.github.io/base16/#flat however I can't even find a way to manually add color values.
wtbob 11y ago
> 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/ http://st.suckless.org/

jkot 11y ago

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

creshal 11y ago
There's no problems with it, it's just slow.
philtar 11y ago
Why?

vidarh 11y ago

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.

hyperion2010 11y ago

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.

delan 11y ago

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.

pdkl95 11y ago
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/ http://terminus-font.sourceforge.net/ [2] http://software.schmorp.de/pkg/rxvt-unicode.html http://software.schmorp.de/pkg/rxvt-unicode.html
- david-given 11y ago
  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 https://goo.gl/photos/pJtpccV8GX9QFkhn6
- userbinator 11y ago
  I prefer the standard IBM VGA font for its readability: https://en.wikipedia.org/wiki/File:Codepage-437.png 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) https://en.wikipedia.org/wiki/Fixed_(typeface)

bnastic 11y ago

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.

4ad 11y ago
Why will you need TTF fonts and antialiasing? The higher the resolution, the less antialiasing you need.
- apenguin 11y ago
  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)

joosters 11y ago

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.

anon4 11y ago

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.

thwarted 11y ago
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.
cuckcuckspruce 11y ago
So you want BeOS?

arethuza 11y ago

What about the real old school approach and try XOFF?

ansible 11y ago
For those that don't remember... That is ctrl-s. XON is ctrl-q.
- sevensor 11y ago
  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.
kps 11y ago
Or, if you're not stuck on Linux, Control-O (or whatever you've set your terminal DISCARD character to).

Steltek 11y ago

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.

AndrewStephens 11y ago

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.

a3n 11y ago

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.