4 ms·
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 repeatab
by 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 agoMinimalism 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 agoIt 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 agoxterm 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.