5 ms·

As much as I love st, I had to stop using it recently. When using a bitmap font in tmux, large amounts of text sent to stdout bring my computer to a standstill.

As much as I love st, I had to stop using it recently. When using a bitmap font in tmux, large amounts of text sent to stdout bring my computer to a standstill. X is using 100% of a single core. I've switched to gnome-terminal and the issue is gone.

nine_k 10y ago
This, along with the generally accepted notion that Gnome Terminal is one of the slowest with output, puts the whole minimalism idea under a serious question. "Do one thing, but do it well", the saying goes.
- microcolonel 10y ago
  Compared to Terminal.app and iTerm2, VTE (the widget underlying Gnome Terminal) is blazing fast.
- otabdeveloper1 10y ago
  > the generally accepted notion that Gnome Terminal is one of the slowest with output Really? Generally accepted by who? My unscientific personal tests show that Gnome Terminal is the fastest and lightest VTE.
  - nine_k 10y ago
    You can run a completely unscientific experiment yourself: take a really large text file, or just use `yes`, and time its full output on several different terminals. yes | head -n 1000000 > two_megs.txt time cat two_megs.txt You will definitely see a difference in the time it takes to complete or a libvte-based terminal, xterm, urvxt, roxterm, etc. OTOH I can google up posts saying that pt shows good results in comparisons like that, apparently using a TTF font. Hopefully the bitmap font performance problem is not due to the general design, but a regression in a special case.
    - davidshepherd7 10y ago
      Huh, interesting results on my machine: urxvt 0.233 gnome 0.474 st 0.515 xterm 1:13.87 times are total real time, in seconds, seem repeatable from a few runs. I was expecting st to blow everything else away given its focus on minimalism, and what the hell is going on with xterm?
      - lvh 10y ago
        Minimalism is a tempting proxy for performance, but it often isn't. rg/ag/pt aren't some of the fastest file searchers around because they're short and don't pull cool tricks. Another example: GNU vs BSD grep, from the author's mouth: https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug... Regex matching: https://swtch.com/~rsc/regexp/regexp1.html https://swtch.com/~rsc/regexp/regexp1.html (It's arguable that a backtracking implementation is not the simplest, although I think it is -- and even if it is, a FSA compiler clearly isn't!) And, finally: people tell me Clojure is slow, and I tell them that it lets me write correct concurrent algorithms I understand. (See alioth shootout results.)
      - bitwize 10y ago
        It could have to do with that xterm is trying to faithfully emulate an actual terminal (viz., VT220 with extensions) by replicating the VT's internal state machine, whereas libvte is trying to approximate the behavior of xterm and cutting corners as it does so. Note that while libvte seems to have greater throughput, its latency is terrible compared to xterm.
      - mlichvar 10y ago
        xterm is showing all data. That's why it's slower. For a fair comparison, you should set the fastScroll X resource, which will allow xterm to suppress screen refresh.
problems 10y ago
Yikes, consider running that through callgrind or something and sending them the output.

nine_k 10y ago

This, along with the generally accepted notion that Gnome Terminal is one of the slowest with output, puts the whole minimalism idea under a serious question. "Do one thing, but do it well", the saying goes.

microcolonel 10y ago
Compared to Terminal.app and iTerm2, VTE (the widget underlying Gnome Terminal) is blazing fast.
otabdeveloper1 10y ago
> the generally accepted notion that Gnome Terminal is one of the slowest with output Really? Generally accepted by who? My unscientific personal tests show that Gnome Terminal is the fastest and lightest VTE.
- nine_k 10y ago
  You can run a completely unscientific experiment yourself: take a really large text file, or just use `yes`, and time its full output on several different terminals. yes | head -n 1000000 > two_megs.txt time cat two_megs.txt You will definitely see a difference in the time it takes to complete or a libvte-based terminal, xterm, urvxt, roxterm, etc. OTOH I can google up posts saying that pt shows good results in comparisons like that, apparently using a TTF font. Hopefully the bitmap font performance problem is not due to the general design, but a regression in a special case.
  - davidshepherd7 10y ago
    Huh, interesting results on my machine: urxvt 0.233 gnome 0.474 st 0.515 xterm 1:13.87 times are total real time, in seconds, seem repeatable from a few runs. I was expecting st to blow everything else away given its focus on minimalism, and what the hell is going on with xterm?
    - lvh 10y ago
      Minimalism is a tempting proxy for performance, but it often isn't. rg/ag/pt aren't some of the fastest file searchers around because they're short and don't pull cool tricks. Another example: GNU vs BSD grep, from the author's mouth: https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug... Regex matching: https://swtch.com/~rsc/regexp/regexp1.html https://swtch.com/~rsc/regexp/regexp1.html (It's arguable that a backtracking implementation is not the simplest, although I think it is -- and even if it is, a FSA compiler clearly isn't!) And, finally: people tell me Clojure is slow, and I tell them that it lets me write correct concurrent algorithms I understand. (See alioth shootout results.)
    - bitwize 10y ago
      It could have to do with that xterm is trying to faithfully emulate an actual terminal (viz., VT220 with extensions) by replicating the VT's internal state machine, whereas libvte is trying to approximate the behavior of xterm and cutting corners as it does so. Note that while libvte seems to have greater throughput, its latency is terrible compared to xterm.
    - mlichvar 10y ago
      xterm is showing all data. That's why it's slower. For a fair comparison, you should set the fastScroll X resource, which will allow xterm to suppress screen refresh.

problems 10y ago

Yikes, consider running that through callgrind or something and sending them the output.