18 ms·

Terminal and shell performance

404 points by darwhy 9y ago

wmf 9y ago
I guess this isn't measuring end-to-end latency which would be discretized in units of frames and would have a constant overhead from the display pipeline. I wonder if the differences between terminals would look much smaller if measured that way.
gue5t 9y ago
It'd be cool if someone would replicate this on Linux under X11 and a few Wayland compositors, and throw urxvt, rxvt, xterm, aterm, and some others in the mix.
- billiob 9y ago
  I'd like to see Terminology perform there.
  - eriknstr 9y ago
    When I first switched from the terminal emulator that came with the first DE I was using (gnome 2?) to urxvt, it seemed very fast. When I later switched to Terminology, it seemed even faster. I've stayed with Terminology. I agree it'd be very interesting to see a proper comparison between Terminology, urxvt and others.
- bennofs 9y ago
  And alacritty (https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty) would be interesting to see as well.
  - deleted 9y ago
    [deleted]
- BenjiWiebe 9y ago
  And Konsole. I love it. Too bad it is tied to KDE libs. It also feels quite snappy to me.
- __s 9y ago
  I use st on wayland: https://github.com/michaelforney/st https://github.com/michaelforney/st with https://github.com/michaelforney/st/pull/8 https://github.com/michaelforney/st/pull/8
mikejmoffitt 9y ago
Interesting results. I have loved XTerm for a long time because it "felt snappy". On MacOS I've always preferred Terminal.app to the often recommended iTerm2 for similar reasons. I think it's funny to have the suckless project page for st go on and on about how XTerm is clunky and old and unmaintainable, but the result of this small and clean minimalist terminal is a closer loser in terminal performance, which subconsciously and consciously detracts from the experience.
- gumby 9y ago
  I've really wondered that too: why is everyone recommending iterm? I'm glad it's just a matter of taste -- I'm perfectly happy with Terminal (and running a shell inside Emacs in my terminal :-).
  - jasonmp85 9y ago
    Good to see these replies here because I've always thought I was crazy. A new bump would come out, I'd try it again, and immediately feel it was too slow before going back to Terminal.app almost immediately.
  - lobster_johnson 9y ago
    iTerm has support for tiling terminal panes within a single window. You can drag any tab to subdivide a pane as much as you like. It's handy for keeping "tail" or "watch" commands or similar visible — the same reasons people use tmux, tiling window managers, so on. The UX isn't perfect, but it's useful enough that I've stuck with iTerm despite the lower performance (and bugs — it's pretty buggy, and the main author rarely seems to address Gitlab issues). iTerm has other nice features. It can run without a title bar (saves space), it does cmd-click-to-open-file, and it has a lot of customization options. I don't really use most of the features; the tiling aspect is the main feature I rely on.
    - Dobbs 9y ago
      I love terminal panes. I'm not sure at this point what comes out of the box and what is custom configuration but I have keybindings for creating vertical and horizontal splits, and additional keybindings for navigating left/right/up/down. My setup is to run MacVim on the left half of the monitor and then iTerm2 on the right half. iTerm is then split into generally three horizontal splits.
chubot 9y ago
If you're sensitive to latency and run Linux, try hitting Ctrl-Alt-F1, and do a little work in console mode at the terminal. (Ctrl-Alt-F7 to get back.) For me this is a great illustration of how much latency there is in the GUI. Not sure if everyone can feel it, but to me console mode is much more immediate and less "stuffy".
- Kenji 9y ago
  Meanwhile on Windows 10 it sometimes takes 2 seconds until the start menu pops up, or sometimes a full second until a right-click context menu comes up. On a clean Windows 10 install on a 3.4GHz PC with plenty of RAM :)
  - steveklabnik 9y ago
    PowerShell gives you an interesting little number when you start it up: Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. Loading personal and system profiles took 542ms.
    - martindevans 9y ago
      Mine does not give me that number - do I need to do something to turn it on?
      - steveklabnik 9y ago
        I don't think so; I didn't explicitly do anything. I have a Lenovo and they put all kinds of crap on there, so maybe this had something to do with it, I dunno.
      - edmccard 9y ago
        >do I need to do something to turn it on? I think it doesn't display if your profiles take less than 500ms to load. EDIT: Just tested with a clean profile with the line "Start-Sleep -m xxxx" for various values of xxxx, and the message has shown up with times just above 500ms but not below.
aorth 9y ago
Interesting to see that both alacritty and Terminal.app are very fast but running tmux inside them kills performance.
- busterarm 9y ago
  I've never once worried or felt bothered by performance issues while running iTerm2, but I have in Terminal.app and I'm a heavy/complex tmux user.
joosters 9y ago
the most common terminal benchmark I see cited (by at least two orders of magnitude) is the rate at which a terminal can display output, often measured by running cat on a large file. This is pretty much as useless a benchmark as I can think of It's a really helpful benchmark, IMO, as it's the main problem I see with different terminals. On a chromebook, most SSH clients are effectively useless because if you accidentally run a command that prints a lot of output (even just 'dmesg'), the terminal locks up for a huge amount of time, seconds or even minutes. You can't even interrupt the output quickly. I appreciate that it's a different problem to the latency that the OP is trying to measure, but as a benchmark, it's actually very useful.
- blattimwind 9y ago
  TFA > The closest thing that I care about is the speed at which I can ^C a command when I’ve accidentally output too much to stdout, but as we’ll see when we look at actual measurements, a terminal’s ability to absorb a lot of input to stdout is only weakly related to its responsiveness to ^C.
- btilly 9y ago
  Later in the same paragraph he addresses your exact problem, and points out that the speed of quitting a command that prints too much output is poorly correlated with the speed of spewing output. Given how easy it is to accidentally spew something that I don't want to wait for, even if it is spewing quickly, I'm squarely with him in not caring about the speed of display. Slow it down to just faster than my eyes can make sense of it, and make ^C fast, and my life will be better.
  - deleted 9y ago
    [deleted]
  - VintageCool 9y ago
    Can we create a metric specifically for that? when SSHed into a remote machine, if I run a command that spews a lot of text, how quickly does the terminal respond to ^C, stop printing text, and return me to the prompt.
diggan 9y ago
Fun test to check how fast the terminal can handle loads of text, run "time head -c 1000000 /dev/urandom" On a MacBookPro11,1 - 2,8 GHz this shows: iTerm2: 2.182 total iTerm2 with tmux: 0.860 total terminal.app: 0.135 total terminal.app with tmux: 0.910 total Surprisingly, iTerm2 is faster with tmux than terminal.app is with tmux. But terminal.app without tmux is the fastest. Anyone knows why the performance with tmux is so different between the both terminals?
- rcthompson 9y ago
  Maybe tmux doesn't pass the full text through to the terminal, and 0.9 seconds is how long tmux takes to work its way through the buffer.
- mbernstein 9y ago
  My iTerm2 is taking 17s vs. 0.3s for Terminal.app. Any idea why yours is an order of magnitude faster?
  - diggan 9y ago
    Hm, have the same CPU? Was tested with build 3.0.15
- RJIb8RBYxzAMX9u 9y ago
  Incidentally, while still fast enough for this test, /dev/[u]random is not very fast on macOS: ~15 MiB/s on my MBP.
darklajid 9y ago
> even the three year old hand-me-down laptop I’m using has 16GB of RAM Oh my.. I wish that was the case. Even current development machines tend to have just 8 around here..
- cannam 9y ago
  I have a (three-year-old) laptop with 16GB at work and another (three-year-old) laptop with 8GB here, and speaking as a C++-etc developer, I never notice any difference. Maybe if you use a substantial number of VM environments.
dahart 9y ago
I love the analysis of terminal latencies! And I'm in full agreement with the overall goal of less latency everywhere. But, of course, I feel like picking a few nits. > And it turns out that when extra latency is A/B tested, people can and do notice latency in the range we’re discussing here. Yes, this is true. But the methodology is important, and the test used doesn't really apply to typing in terminals. The test isn't a "type and see if you can tell it's slow" test, it's a hit the mark hand-eye coordination test, something you don't do when typing text. Latency when playing Guitar Hero is super duper important, way more important than most other games, which is why they have a latency calibrator right in the game. Latency when playing a Zelda game is a lot less important, but they still try very hard to reduce latency. The same people who can distinguish between 2ms of difference in a drum beat also can't distinguish between an extra 30ms of response time when they click a button in a dialog box. I'd like to see a stronger justification for why lower latency in a terminal is just as important as it is for hand-eye coordination tasks in games. ~2 msec (mouse) 8 msec (average time we wait for the input to be processed by the game) 16.6 (game simulation) 16.6 (rendering code) 16.6 (GPU is rendering the previous frame, current frame is cached) 16.6 (GPU rendering) 8 (average for missing the vsync) 16.6 (frame caching inside of the display) 16.6 (redrawing the frame) 5 (pixel switching) I find this list pretty strange. It's generally right - there are a bunch of sources of latency. But having done optimization for game consoles for a decade, this explanation of game latency feels kinda weird. Games that actually run at 60fps usually do not have greater than 100ms latency. They also don't miss vsync every other frame on average, that 8ms thrown in there looks bizarre to me. Render code and GPU rendering are normally the same thing. Both current and previous frame GPU rendering is listed, huh? Sim & render code run in parallel, not serially. The author even said that in his article, but lists them separately... ? Consumer TVs come with like 50ms of latency by default. That's often half of it right there. Games are often triple-buffered too, that accounts for some of it. The ~2ms right at the top belongs in the 8ms wait, it disappears completely. I just get the feeling the author of this list was trying hard to pad the numbers to make his point, it feels a like a very hand-wavy analysis masquerading as a proper accounting of latency.
- batmansmk 9y ago
  It is gonna be a totally experimental feedback, but nonetheless it may help you relating to the importance of fast feedback latency ; the best stays to experience it yourself. I noticed during my thesis on realtime systems that my brain had difficulties compensating for latency, even more for jitter (inconsistent latency). I do more typos when I have a high latency. I notice it when playing music in a high latency context, or when the ssh connection has a high ping. We did the experiment slowing down the click of the mouse by 100ms. Users hated the results. I'm also more productive if I can notice my typos 100ms earlier, or confirm that everything I previously typed is good earlier. Even if it takes me 500ms to process the information displayed on screen, it stays on the critical path of the overall task speed performance.
def- 9y ago
Was curious and tried this out a bit on Linux+X11 on an i7 6700k with the igpu: stdout [MB/s] idle 50 [ms] urxvt 34.9 19.8 xterm 2.2 1.9 rxvt 4.3 7.0 aterm 6.0 7.0 konsole 13.1 13.0 note: stops moving when printing large file terminator 9.1 29.4 note: stops moving when printing large file st 23.0 11.2 alacritty 45.5 15.5
- cat199 9y ago
  Nice.. I've apparently gravitated myself to the fastest of the lot naturally.. Side note: was supervising some kid who absolutely couldn't believe that the reason his 'workstation was locking up' was that he was catting giant logfiles in a second pane of his single-process gnome terminal.. I told him to use Xterm or something else, since they spawned one process per window, and he tried for a while, but went back, and continued to complain, because just couldn't believe that the terminal could get bogged down, and further, missed his pretty anti-aliased fonts. Sigh.
- sim- 9y ago
  Can you paste or describe your measuring technique?
  - def- 9y ago
    For the throughput I created a file with 1 GB of random source code and ran `time cat file` Latency for input: https://github.com/pavelfatin/typometer https://github.com/pavelfatin/typometer
- loeg 9y ago
  Could you try terminology as well?
  - FractalNerve 9y ago
    I really like terminology :) Can you test yakuake and kmscon[0] also? EDIT: [0] https://www.freedesktop.org/wiki/Software/kmscon/ https://www.freedesktop.org/wiki/Software/kmscon/
jwilm 9y ago
We can do better in Alacritty. For those interested, I've filed a bug on our issue tracker about where this latency is coming from and what can be done: https://github.com/jwilm/alacritty/issues/673 https://github.com/jwilm/alacritty/issues/673 At the end of the day, there is a trade off to be made. Terminals (or any program, really) can have 1-frame input latency (typically 1/60sec) and give up v-sync and tearing results, or they can have a worst-case 2-frame input latency with v-sync, and then you're looking at 2/60sec or ~32ms.
- zokier 9y ago
  Triple buffering solves the latency issue of vsync latency by trading off buring additional cpu/gpu time, bringing the worst-case latency back to 1 frame.
  - taw55 9y ago
    I don't think that's correct. The way I understand it tripple buffering adds latency in exchange for higher sub display hz framerates. Double buffering renders the next frame while displaying the current. That results in latency of 1 frame since input. Triple buffering adds another frame to the queue, resulting in a 2 frame lag. With double buffering the framerate gets cut in half if it cannot meet vsync, with triple buffering it can also get cut in thirds. So double buffering is 60 -> 30, where the frame lasts 2 refreshes. Triple is 60 -> 40, where one frame is displayed for 1 refresh and another is displayed for 2. Nowadays it's probably better to use adaptive vsync, which simply disables vsync when the framerate drops. This will reintroduce tearing, which might be preferable in fast action games.
    - speleo_engr 9y ago
      Triple buffering confusingly means different things. Both you and the OP are correct. The OP meant something in line with what Wikipedia says: https://en.wikipedia.org/wiki/Multiple_buffering#Triple_buffering https://en.wikipedia.org/wiki/Multiple_buffering#Triple_buff... "In triple buffering the program has two back buffers and can immediately start drawing in the one that is not involved in such copying. The third buffer, the front buffer, is read by the graphics card to display the image on the monitor. Once the image has been sent to the monitor, the front buffer is flipped with (or copied from) the back buffer holding the most recent complete image. Since one of the back buffers is always complete, the graphics card never has to wait for the software to complete. Consequently, the software and the graphics card are completely independent and can run at their own pace. Finally, the displayed image was started without waiting for synchronization and thus with minimum lag.[1] Due to the software algorithm not having to poll the graphics hardware for monitor refresh events, the algorithm is free to run as fast as possible. This can mean that several drawings that are never displayed are written to the back buffers. Nvidia has implemented this method under the name "Fast sync"."
cannam 9y ago
Interesting article, but I don't quite get it. I'd imagine that terminal users will often be looking at the last bit of output as they type, and hardly looking at the thing they're typing at all (one glance before hitting Return). They aren't going to notice a bit of latency. And terminals are often used to communicate over networks that introduce a lot more latency than any of the measurements here. I think, for me, this is a bit like the sales pitch for Alacritty -- fastest terminal ever as long as you don't mind that it doesn't scroll. Someone is using their terminal very differently from the way I use mine.
- blunte 9y ago
  It depends how you use a terminal. If you type a lot of commands, and you use emacs keys to jump around within the current line you're typing (like ctrl-p to go up to the previously entered command, ctrl-a to jump to the beginning of the line, replace the first word, etc.), those latencies add up. Basically we want the stuff in our brains to be able to manifest itself as fast as we're thinking it. Already having to drive human hands to make this happen is a big penalty; we don't need unnecessary extra latency if it can be helped. Still waiting for that neural interface... plug me in please.
mrbill 9y ago
I wonder how much performance hit font antialiasing in iterm2 causes, or if it was turned on during these tests.
- gjvc 9y ago
  font antialiasing on the original OS X completely destroyed performance in the terminal and gave the impression that that the whole system was slow.
portlander12345 9y ago
Slightly off-topic, but this reminded me of a mystery: Does anyone else experience that bash takes a long and variable time to start, on many systems and without any fancy setup of any kind? What can a shell be doing that it takes three or four seconds to start?
- cturner 9y ago
  Is part of this an experience of cygwin? Forking is slow under cygwin. If you can get to a recent Windows 10 with local admin rights, you can install windows-services for linux, and bash should perform well even on ten-year-old hardware. If you getting unusual slowness in linux/BSD, some things to check: (1) any significant overhead on the system that could be making forking slow; (2) some option in your $HOME/.bashrc that is adding latency, e.g., indexing options or dynamic stuff in your PS1; (3) unusual filesystem stuff, e.g., your home directory is mounted over NFS. If you're in linux and it is reproducible, run strace against a bash launch, and ctrl+c it when it gets stuck. Have a look at the recent system calls.
  - portlander12345 9y ago
    This is on Mac OS. I might try the tracing idea though.
- chubot 9y ago
  I don't have this experience -- I highly suspect NFS or another network file system. On my system, hitting Ctrl-Shift-T inside xterm is almost instant, and that starts a bash process. Likewise for Ctrl-B C in tmux. Bash's startup files are annoying, but you can probably pinpoint the problem with strace. Or maybe try running: strace bash vs. strace bash --norc --rcfile=/dev/null However this isn't the full story because bash's startup sequence is a nightmare and neither of those is likely to be exactly what happens when you're starting a new shell.
- brown9-2 9y ago
  An easy way to figure this out is to add `set -x` to .bash_profile or its equivalent.
gnachman 9y ago
iTerm2 author here. I'll spend some time looking into iTerm2's latency. I'm sure there are some low-hanging fruit here. But there have also been a handful of complaints that latency was too low—when you hit return at the shell prompt, the next frame drawn should include the next shell prompt, not the cursor on the next line before the new shell prompt has been read. So it's tricky to get right, especially considering how slow macOS's text drawing is. If I could draw a whole frame in a reasonable amount of time, this problem would be much easier! But I can't. Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. The deprecated core graphics API is significantly faster, but it does a not-so-great job at anything but ASCII text, doesn't support ligatures, etc. Using layers helps on some machines and hurts on others. You also lose the ability to blur the contents behind the window, which is very popular. It also introduces a lot of bugs—layers on macOS are not as fully baked as they are on iOS. So this doesn't seem like a productive avenue. How is Terminal.app as fast as it is? I don't know for sure. I do know that they ditched NSScrollView. They glued some NSScrollers onto a custom NSView subclass and (presumably) copy-pasted a bunch of scrolling inertia logic into their own code. AFAICT that's the main difference between Terminal and iTerm2, but it's just not feasible for a third-party developer to do.
- nneonneo 9y ago
  What text rendering approach does Terminal.app use, then? Is it also some custom thing? Maybe it does its own font caching - given that the terminal uses fixed-size fonts with simple fonts (fixed-width, no kerning, ligatures, etc.), it seems quite believable that they would avoid the overhead of CoreText (which has to handle a LOT more font complexity). With regards to the shell prompt, I'm almost positive that Terminal.app is using some heuristic to read the prompt after a <return>. A little experiment with a tunable spinloop and a fake prompt in C suggests that Terminal.app waits for about 1ms after a return character before updating the screen: a delay of 950us produces an "instant" prompt, while a delay of 1050us shows the cursor at the start of the next line. As the article notes, a 1ms delay is not really noticeable, and that kind of delay only has to happen in a handful of situations.
  - gnachman 9y ago
chuckdries 9y ago
I'm surprised Hyper did as well as it did on the latency test, after all it does run in Electron, which I'd expect to add a lot of overhead between keypress and text display
- Tyriar 9y ago
  You should expect latency similar to a web app in Chrome, just that this has a backing pty processing the input and output.
nneonneo 9y ago
I think one thing that this really points out is just how much care Apple has poured into Terminal.app. It's very good, and every time I have to use another terminal application (ugh conhost.exe) I am reminded of this. It's got a bunch of really thoughtful little features (showing what processes are attached to the current pty, option-clicking to move the cursor rapidly, full mouse support for apps like vim, good linewrap detection, and recently support for rich-text copy/paste which is useful for showing coloured terminal output, etc. etc.), and it remains really fast and snappy despite these features. On a related note, I am big into latency analysis and driving down latency in interactive systems. I'm quite familiar with the touchscreen work cited at the top, and having played with the system I can attest that <1ms latency feels actually magical. At that level, it really doesn't feel like any touchscreen you've ever used - it genuinely feels like a physical object you're dragging around (the first demo of the system only let you drag a little rectangle around a projected screen). It's amazing what they had to do to get the latency down - a custom DLP projector with hacked firmware that could only display a little square at a specified position at thousands of FPS, a custom touchscreen controller, and a direct line between the two. No OS, no windowing system, nada. After seeing that demo, I can't help but believe that latency is the one thing that will make or break virtual reality - the one thing that separates "virtual" from "reality". I want to build a demo someday that does the latency trick in VR - a custom rig that displays ultra-simple geometry that has sub-millisecond latency to human head movement. I will bet that even simple geometry will feel more realistic than the most complex scene at 90 FPS.
- vortico 9y ago
  >On a related note, I am big into latency analysis and driving down latency in interactive systems. I'm afraid there aren't many of us that care about the subtle details of interaction that mean the most to one's experience. Working in audio, I know the difference between hitting a button and hearing a sound 40ms afterwards, and 4ms afterwords. I would much prefer to use the 4ms, even if it means sacrificing half of the system's features. I feel like such a product will never reach the market, because the market will think they need lots of features, which results in a sacrifice of latency and other UI consistencies. There's always some developer writing the weakest link of an otherwise perfect system. For example, the CPU/GPU hardware, kernel, and browser's accelerated rendering are all engineered with millions of man-hours to be as blazingly fast as possible, and then a web developer comes along and puts a single setInterval() call in their online game or something, and all the optimization benefit goes to the trash. Or, because animation is a trend in UI design right now, developers purposely put in hundreds of milliseconds of delay between common actions like minimizing windows, switching desktops, scrolling, opening/closing apps on mobile, etc. Basically in order for your dream of true virtual reality to be achieved, the principles and respect for low latency has to be maintained across the whole system's stack, especially the higher-level parts.
tome 9y ago
How can st be so slow? It's tiny and hardly does anything!
- wmf 9y ago
  Maybe it's doing hardly anything one character at a time.
- carlesfe 9y ago
  Because it's running inside XQuartz on macOS. There is another line on the graph, "linux-st" with much better results.
chillee 9y ago
One other thing to note is that compositors seem to add a fairly large amount of latency. I ran the app linked in the "Typing with Pleasure" post and I saw a roughly ~20ms improvement across various text editors with the compositor turned off (I'm using Termite with Compton as my compositor). http://imgur.com/0G3qbpr http://imgur.com/0G3qbpr
mrob 9y ago
The common LibVTE-based terminals have problems with latency because they're deliberately capped at 40fps. Xterm doesn't have this problem. Gedit gained this problem when it switched to GTK3. The forced animation for scrolling doesn't help. Mousepad still has low latency, at least in the version included with Debian Unstable, but I worry that port of XFCE to GTK3 will make it as bad as GNOME.
chubot 9y ago
If you care about end-to-end latency, I highly recommend this talk by John Carmack: https://www.youtube.com/watch?v=lHLpKzUxjGk https://www.youtube.com/watch?v=lHLpKzUxjGk This talk blew my mind and made me feel like a terrible engineer. He's talking about end-to-end latency in VR, which actually has a commercial motivation because VR products with high latency will make you sick. (this obviously doesn't happen with shells and terminals!) He's talking about the buffering and filtering at every step of the way. And it's not just software -- sensors have their own controllers to do filtering, which requires buffering, before your OS kernel can even SEE the the first byte, let alone user space. On the other side, display devices and audio output devices also do nontrivial processing after you've sent them your data. It's an integrated hardware/software problem and Carmack is great at explaining it! It's a dense, long-ish talk, but worth it.
Tyriar 9y ago
I work on the VS Code terminal/xterm.js[1]. Hyper which currently uses a fork of hterm, is in the process of moving over to xterm.js due to the feature/performance improvements we've made over the past 12 months. Hyper's 100% CPU/crash issue[2] for example should be fixed through some clever management of the buffer and minimizing changing the DOM when the viewport will completely change on the next frame. I'd love to see the same set of tests on Hyper after they adopt xterm.js and/or on VS Code's terminal. Related: I'm currently in the process of reducing xterm.js' memory consumption[3] in order to support truecolor without a big memory hit. [1]: https://github.com/sourcelair/xterm.js https://github.com/sourcelair/xterm.js [2]: https://github.com/zeit/hyper/issues/94 https://github.com/zeit/hyper/issues/94 [3]: https://github.com/sourcelair/xterm.js/issues/791 https://github.com/sourcelair/xterm.js/issues/791
cat199 9y ago
So, on the other side, anyone want to build a true 'terminal emulator' that has baud-speed emulation? top just doesn't look the same without the changes trickling down the screen, matrix like.. Thankfully I can run GlassTTY font connected to the KVM serial console for a near approximation.. but it's still too fast :) Grew up in the VC/GUI transition era, but buying a vt220 and running it at 19200 on a used Vax taught me a Zen of command line that nothing else could... Not only did you have to think about what the command would do, but also how much text it would display, and whether you'd need to reboot the terminal after it got hosed up...
- angus-g 9y ago
  You could use cool-retro-term[0] for the visual side, but that doesn't support baud rate emulation either. Maybe you could pipe things through `pv` with the `-L` flag to limit speed? [0]: https://github.com/Swordfish90/cool-retro-term https://github.com/Swordfish90/cool-retro-term
- acuozzo 9y ago
  > So, on the other side, anyone want to build a true 'terminal emulator' that has baud-speed emulation? So this isn't exactly the same, but I improved my Vim muscle memory considerably by running the MS-DOS version of Vim inside of DOSBox, reducing its speed of emulation to the lowest option, and finding the most efficient ways to edit files at a decent pace by making use of the best command sequences possible at any given point in time.
chubot 9y ago
How did he actually measure the latency in this article? Doesn't measuring keypresses to display latency require special hardware? All tests were done on a dual core 2.6GHz 13” Mid-2014 Macbook pro. The machine has 16GB of RAM and a 2560x1600 screen. The OS X version was 10.12.5. Some tests were done in Linux (Lubuntu 16.04) to get a comparison between macOS and Linux. 10k keypresses were for each latency measurements. Latency measurements were done with the . key and throughput was done with default base32 output, which is all plain ASCII text. This is significant. For example, terminal.app appears to slow down when outputting non-latin unicode characters.
adekok 9y ago
Latency is why I could never use a WYSIWYG word processor. While I don't like VI that much, it's latency is low enough that it's not a problem. i.e. I press a key, and miracle of miracles, the character appears on the screen. Using a WYSIWYG word processor, there's enough latency between keypress and visual update that I find them impossible to use. When Apple came out with Pages, it was apparent that they paid strong attention to latency. That means the latency is small enough that (for me) using it isn't an exercise in frustration.
- copperx 9y ago
  Mellel is a word processor app with lower latency than Pages.
- glitch003 9y ago
  > I press a key, and miracle of miracles, the character appears on the screen. As long as you press "i" first! :)
iClaudiusX 9y ago
I found this note in the appendix interesting with respect to why we don't seem to notice this latency > Terminals were fullscreened before running tests. This affects test results, and resizing the terminal windows can and does significantly change performance (e.g., it’s possible to get hyper to be slower than iterm2 by changing the window size while holding everything else constant). Perhaps we don't notice because it's so much lower at window sizes much less than fullscreen?
tomsmeding 9y ago
> even the three year old hand-me-down laptop I’m using has 16GB of RAM > on my old and now quite low-end laptop Trust me, that's not a low-end laptop. Either that has the shittiest cpu ever and a terribly mismatched amount of memory, or the author's view of that is high-end or low-end is skewed; in either case, what's low-end nowadays would be ≤4GB RAM. 16GB is LOTS, useful for developers that run large builds and/or VM's regularly. I very much like the rest of the article though, would love to see some latency improvements here and there!
- arghwhat 9y ago
  It may very well be your view that is skewed. For user-facing terminals/workstations, I would consider ≤8GB low-end ("unusable"). 16GB would be mid-low ("usable"), 32GB would be mid-high ("comfortable"), ≥64GB would be high ("good"). For servers, ≤64GB is low-end, ≥512GB being high-end. That 8GB would be considered low-end does not mean that no one uses it, though. Some people might still rock 2GB laptops, or use the original 256MB Pi 1 as a light desktop.
  - tomsmeding 9y ago
    Apparently that's true then. I'm in the Netherlands, so maybe the US is different in this regard. Thanks for clearing up!
    - 59nadir 9y ago
      No, you're completely right in that 16 GB RAM is not considered low-end. You only have to browse for laptops for about 2 minutes to discover that 16 isn't at all "low-end".
      - arghwhat 9y ago
        I think you missed the point I was trying to make entirely (that people's definitions of "low end" differ, although "low-end" steadily moves up), but from that perspective: - 8GB is easily available and what most cheap laptops sport, - 16GB is either default or an addon for cheaper laptops, - 32GB is a premium that is not always available, and - 64GB is usually only available in huge workstation or gamer "laptops", although there are some decent-size Dells with it. While those are not my choice of metrics, they do seem to support the "low", "mid-low", "mid-high" and "high" labels I personally added. At most, you could argue that ≤8GB is low, 16GB is mid and ≥32GB is high. 10 years ago, 16GB would have been high-end for a laptop, but no more.
wallstquant 9y ago
It would also be great to see how these scale with terminal size. I personally use iterm2 but after switching to a new Macbook pro this year with two 5k displays it's noticeably slower. I'm assuming some O(n^2) scaling behind the scenes but I haven't measured anything myself. Still, @gnachman I love your term especially with terminalplots.jl and drawing Julia repl images inline.
victorhooi 9y ago
I want to try Alacritty on OSX - but the big turnoff for me is the lack of binaries. However, I don't know if that's intentional, because they don't think it's ready yet for people who won't install/compile the whole Rust stack from scratch?
- steveklabnik 9y ago
  > Precompiled binaries will eventually be made available on supported platforms. This is minimally blocked on a stable config format. For now, Alacritty must be built from source. https://github.com/jwilm/alacritty#about https://github.com/jwilm/alacritty#about

404 points by darwhy 9y ago

wmf 9y ago

I guess this isn't measuring end-to-end latency which would be discretized in units of frames and would have a constant overhead from the display pipeline. I wonder if the differences between terminals would look much smaller if measured that way.

gue5t 9y ago

It'd be cool if someone would replicate this on Linux under X11 and a few Wayland compositors, and throw urxvt, rxvt, xterm, aterm, and some others in the mix.

billiob 9y ago
I'd like to see Terminology perform there.
- eriknstr 9y ago
  When I first switched from the terminal emulator that came with the first DE I was using (gnome 2?) to urxvt, it seemed very fast. When I later switched to Terminology, it seemed even faster. I've stayed with Terminology. I agree it'd be very interesting to see a proper comparison between Terminology, urxvt and others.
bennofs 9y ago
And alacritty (https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty) would be interesting to see as well.
- deleted 9y ago
  [deleted]
BenjiWiebe 9y ago
And Konsole. I love it. Too bad it is tied to KDE libs. It also feels quite snappy to me.
__s 9y ago
I use st on wayland: https://github.com/michaelforney/st https://github.com/michaelforney/st with https://github.com/michaelforney/st/pull/8 https://github.com/michaelforney/st/pull/8

mikejmoffitt 9y ago

Interesting results. I have loved XTerm for a long time because it "felt snappy". On MacOS I've always preferred Terminal.app to the often recommended iTerm2 for similar reasons. I think it's funny to have the suckless project page for st go on and on about how XTerm is clunky and old and unmaintainable, but the result of this small and clean minimalist terminal is a closer loser in terminal performance, which subconsciously and consciously detracts from the experience.

gumby 9y ago
I've really wondered that too: why is everyone recommending iterm? I'm glad it's just a matter of taste -- I'm perfectly happy with Terminal (and running a shell inside Emacs in my terminal :-).
- jasonmp85 9y ago
  Good to see these replies here because I've always thought I was crazy. A new bump would come out, I'd try it again, and immediately feel it was too slow before going back to Terminal.app almost immediately.
- lobster_johnson 9y ago
  iTerm has support for tiling terminal panes within a single window. You can drag any tab to subdivide a pane as much as you like. It's handy for keeping "tail" or "watch" commands or similar visible — the same reasons people use tmux, tiling window managers, so on. The UX isn't perfect, but it's useful enough that I've stuck with iTerm despite the lower performance (and bugs — it's pretty buggy, and the main author rarely seems to address Gitlab issues). iTerm has other nice features. It can run without a title bar (saves space), it does cmd-click-to-open-file, and it has a lot of customization options. I don't really use most of the features; the tiling aspect is the main feature I rely on.
  - Dobbs 9y ago
    I love terminal panes. I'm not sure at this point what comes out of the box and what is custom configuration but I have keybindings for creating vertical and horizontal splits, and additional keybindings for navigating left/right/up/down. My setup is to run MacVim on the left half of the monitor and then iTerm2 on the right half. iTerm is then split into generally three horizontal splits.

chubot 9y ago

If you're sensitive to latency and run Linux, try hitting Ctrl-Alt-F1, and do a little work in console mode at the terminal. (Ctrl-Alt-F7 to get back.) For me this is a great illustration of how much latency there is in the GUI. Not sure if everyone can feel it, but to me console mode is much more immediate and less "stuffy".

Kenji 9y ago
Meanwhile on Windows 10 it sometimes takes 2 seconds until the start menu pops up, or sometimes a full second until a right-click context menu comes up. On a clean Windows 10 install on a 3.4GHz PC with plenty of RAM :)
- steveklabnik 9y ago
  PowerShell gives you an interesting little number when you start it up: Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. Loading personal and system profiles took 542ms.
  - martindevans 9y ago
    Mine does not give me that number - do I need to do something to turn it on?
    - steveklabnik 9y ago
      I don't think so; I didn't explicitly do anything. I have a Lenovo and they put all kinds of crap on there, so maybe this had something to do with it, I dunno.
    - edmccard 9y ago
      >do I need to do something to turn it on? I think it doesn't display if your profiles take less than 500ms to load. EDIT: Just tested with a clean profile with the line "Start-Sleep -m xxxx" for various values of xxxx, and the message has shown up with times just above 500ms but not below.

aorth 9y ago

Interesting to see that both alacritty and Terminal.app are very fast but running tmux inside them kills performance.

busterarm 9y ago
I've never once worried or felt bothered by performance issues while running iTerm2, but I have in Terminal.app and I'm a heavy/complex tmux user.

joosters 9y ago

the most common terminal benchmark I see cited (by at least two orders of magnitude) is the rate at which a terminal can display output, often measured by running cat on a large file. This is pretty much as useless a benchmark as I can think of It's a really helpful benchmark, IMO, as it's the main problem I see with different terminals. On a chromebook, most SSH clients are effectively useless because if you accidentally run a command that prints a lot of output (even just 'dmesg'), the terminal locks up for a huge amount of time, seconds or even minutes. You can't even interrupt the output quickly. I appreciate that it's a different problem to the latency that the OP is trying to measure, but as a benchmark, it's actually very useful.

blattimwind 9y ago
TFA > The closest thing that I care about is the speed at which I can ^C a command when I’ve accidentally output too much to stdout, but as we’ll see when we look at actual measurements, a terminal’s ability to absorb a lot of input to stdout is only weakly related to its responsiveness to ^C.
btilly 9y ago
Later in the same paragraph he addresses your exact problem, and points out that the speed of quitting a command that prints too much output is poorly correlated with the speed of spewing output. Given how easy it is to accidentally spew something that I don't want to wait for, even if it is spewing quickly, I'm squarely with him in not caring about the speed of display. Slow it down to just faster than my eyes can make sense of it, and make ^C fast, and my life will be better.
- deleted 9y ago
  [deleted]
- VintageCool 9y ago
  Can we create a metric specifically for that? when SSHed into a remote machine, if I run a command that spews a lot of text, how quickly does the terminal respond to ^C, stop printing text, and return me to the prompt.

diggan 9y ago

Fun test to check how fast the terminal can handle loads of text, run "time head -c 1000000 /dev/urandom" On a MacBookPro11,1 - 2,8 GHz this shows: iTerm2: 2.182 total iTerm2 with tmux: 0.860 total terminal.app: 0.135 total terminal.app with tmux: 0.910 total Surprisingly, iTerm2 is faster with tmux than terminal.app is with tmux. But terminal.app without tmux is the fastest. Anyone knows why the performance with tmux is so different between the both terminals?

rcthompson 9y ago
Maybe tmux doesn't pass the full text through to the terminal, and 0.9 seconds is how long tmux takes to work its way through the buffer.
mbernstein 9y ago
My iTerm2 is taking 17s vs. 0.3s for Terminal.app. Any idea why yours is an order of magnitude faster?
- diggan 9y ago
  Hm, have the same CPU? Was tested with build 3.0.15
RJIb8RBYxzAMX9u 9y ago
Incidentally, while still fast enough for this test, /dev/[u]random is not very fast on macOS: ~15 MiB/s on my MBP.

darklajid 9y ago

> even the three year old hand-me-down laptop I’m using has 16GB of RAM Oh my.. I wish that was the case. Even current development machines tend to have just 8 around here..

cannam 9y ago
I have a (three-year-old) laptop with 16GB at work and another (three-year-old) laptop with 8GB here, and speaking as a C++-etc developer, I never notice any difference. Maybe if you use a substantial number of VM environments.

dahart 9y ago

I love the analysis of terminal latencies! And I'm in full agreement with the overall goal of less latency everywhere. But, of course, I feel like picking a few nits. > And it turns out that when extra latency is A/B tested, people can and do notice latency in the range we’re discussing here. Yes, this is true. But the methodology is important, and the test used doesn't really apply to typing in terminals. The test isn't a "type and see if you can tell it's slow" test, it's a hit the mark hand-eye coordination test, something you don't do when typing text. Latency when playing Guitar Hero is super duper important, way more important than most other games, which is why they have a latency calibrator right in the game. Latency when playing a Zelda game is a lot less important, but they still try very hard to reduce latency. The same people who can distinguish between 2ms of difference in a drum beat also can't distinguish between an extra 30ms of response time when they click a button in a dialog box. I'd like to see a stronger justification for why lower latency in a terminal is just as important as it is for hand-eye coordination tasks in games. ~2 msec (mouse) 8 msec (average time we wait for the input to be processed by the game) 16.6 (game simulation) 16.6 (rendering code) 16.6 (GPU is rendering the previous frame, current frame is cached) 16.6 (GPU rendering) 8 (average for missing the vsync) 16.6 (frame caching inside of the display) 16.6 (redrawing the frame) 5 (pixel switching) I find this list pretty strange. It's generally right - there are a bunch of sources of latency. But having done optimization for game consoles for a decade, this explanation of game latency feels kinda weird. Games that actually run at 60fps usually do not have greater than 100ms latency. They also don't miss vsync every other frame on average, that 8ms thrown in there looks bizarre to me. Render code and GPU rendering are normally the same thing. Both current and previous frame GPU rendering is listed, huh? Sim & render code run in parallel, not serially. The author even said that in his article, but lists them separately... ? Consumer TVs come with like 50ms of latency by default. That's often half of it right there. Games are often triple-buffered too, that accounts for some of it. The ~2ms right at the top belongs in the 8ms wait, it disappears completely. I just get the feeling the author of this list was trying hard to pad the numbers to make his point, it feels a like a very hand-wavy analysis masquerading as a proper accounting of latency.

batmansmk 9y ago
It is gonna be a totally experimental feedback, but nonetheless it may help you relating to the importance of fast feedback latency ; the best stays to experience it yourself. I noticed during my thesis on realtime systems that my brain had difficulties compensating for latency, even more for jitter (inconsistent latency). I do more typos when I have a high latency. I notice it when playing music in a high latency context, or when the ssh connection has a high ping. We did the experiment slowing down the click of the mouse by 100ms. Users hated the results. I'm also more productive if I can notice my typos 100ms earlier, or confirm that everything I previously typed is good earlier. Even if it takes me 500ms to process the information displayed on screen, it stays on the critical path of the overall task speed performance.

def- 9y ago

Was curious and tried this out a bit on Linux+X11 on an i7 6700k with the igpu: stdout [MB/s] idle 50 [ms] urxvt 34.9 19.8 xterm 2.2 1.9 rxvt 4.3 7.0 aterm 6.0 7.0 konsole 13.1 13.0 note: stops moving when printing large file terminator 9.1 29.4 note: stops moving when printing large file st 23.0 11.2 alacritty 45.5 15.5

cat199 9y ago
Nice.. I've apparently gravitated myself to the fastest of the lot naturally.. Side note: was supervising some kid who absolutely couldn't believe that the reason his 'workstation was locking up' was that he was catting giant logfiles in a second pane of his single-process gnome terminal.. I told him to use Xterm or something else, since they spawned one process per window, and he tried for a while, but went back, and continued to complain, because just couldn't believe that the terminal could get bogged down, and further, missed his pretty anti-aliased fonts. Sigh.
sim- 9y ago
Can you paste or describe your measuring technique?
- def- 9y ago
  For the throughput I created a file with 1 GB of random source code and ran `time cat file` Latency for input: https://github.com/pavelfatin/typometer https://github.com/pavelfatin/typometer
loeg 9y ago
Could you try terminology as well?
- FractalNerve 9y ago
  I really like terminology :) Can you test yakuake and kmscon[0] also? EDIT: [0] https://www.freedesktop.org/wiki/Software/kmscon/ https://www.freedesktop.org/wiki/Software/kmscon/

jwilm 9y ago

We can do better in Alacritty. For those interested, I've filed a bug on our issue tracker about where this latency is coming from and what can be done: https://github.com/jwilm/alacritty/issues/673 https://github.com/jwilm/alacritty/issues/673 At the end of the day, there is a trade off to be made. Terminals (or any program, really) can have 1-frame input latency (typically 1/60sec) and give up v-sync and tearing results, or they can have a worst-case 2-frame input latency with v-sync, and then you're looking at 2/60sec or ~32ms.

zokier 9y ago
Triple buffering solves the latency issue of vsync latency by trading off buring additional cpu/gpu time, bringing the worst-case latency back to 1 frame.
- taw55 9y ago
  I don't think that's correct. The way I understand it tripple buffering adds latency in exchange for higher sub display hz framerates. Double buffering renders the next frame while displaying the current. That results in latency of 1 frame since input. Triple buffering adds another frame to the queue, resulting in a 2 frame lag. With double buffering the framerate gets cut in half if it cannot meet vsync, with triple buffering it can also get cut in thirds. So double buffering is 60 -> 30, where the frame lasts 2 refreshes. Triple is 60 -> 40, where one frame is displayed for 1 refresh and another is displayed for 2. Nowadays it's probably better to use adaptive vsync, which simply disables vsync when the framerate drops. This will reintroduce tearing, which might be preferable in fast action games.
  - speleo_engr 9y ago
    Triple buffering confusingly means different things. Both you and the OP are correct. The OP meant something in line with what Wikipedia says: https://en.wikipedia.org/wiki/Multiple_buffering#Triple_buffering https://en.wikipedia.org/wiki/Multiple_buffering#Triple_buff... "In triple buffering the program has two back buffers and can immediately start drawing in the one that is not involved in such copying. The third buffer, the front buffer, is read by the graphics card to display the image on the monitor. Once the image has been sent to the monitor, the front buffer is flipped with (or copied from) the back buffer holding the most recent complete image. Since one of the back buffers is always complete, the graphics card never has to wait for the software to complete. Consequently, the software and the graphics card are completely independent and can run at their own pace. Finally, the displayed image was started without waiting for synchronization and thus with minimum lag.[1] Due to the software algorithm not having to poll the graphics hardware for monitor refresh events, the algorithm is free to run as fast as possible. This can mean that several drawings that are never displayed are written to the back buffers. Nvidia has implemented this method under the name "Fast sync"."

cannam 9y ago

Interesting article, but I don't quite get it. I'd imagine that terminal users will often be looking at the last bit of output as they type, and hardly looking at the thing they're typing at all (one glance before hitting Return). They aren't going to notice a bit of latency. And terminals are often used to communicate over networks that introduce a lot more latency than any of the measurements here. I think, for me, this is a bit like the sales pitch for Alacritty -- fastest terminal ever as long as you don't mind that it doesn't scroll. Someone is using their terminal very differently from the way I use mine.

blunte 9y ago
It depends how you use a terminal. If you type a lot of commands, and you use emacs keys to jump around within the current line you're typing (like ctrl-p to go up to the previously entered command, ctrl-a to jump to the beginning of the line, replace the first word, etc.), those latencies add up. Basically we want the stuff in our brains to be able to manifest itself as fast as we're thinking it. Already having to drive human hands to make this happen is a big penalty; we don't need unnecessary extra latency if it can be helped. Still waiting for that neural interface... plug me in please.

mrbill 9y ago

I wonder how much performance hit font antialiasing in iterm2 causes, or if it was turned on during these tests.

gjvc 9y ago
font antialiasing on the original OS X completely destroyed performance in the terminal and gave the impression that that the whole system was slow.

portlander12345 9y ago

Slightly off-topic, but this reminded me of a mystery: Does anyone else experience that bash takes a long and variable time to start, on many systems and without any fancy setup of any kind? What can a shell be doing that it takes three or four seconds to start?

cturner 9y ago
Is part of this an experience of cygwin? Forking is slow under cygwin. If you can get to a recent Windows 10 with local admin rights, you can install windows-services for linux, and bash should perform well even on ten-year-old hardware. If you getting unusual slowness in linux/BSD, some things to check: (1) any significant overhead on the system that could be making forking slow; (2) some option in your $HOME/.bashrc that is adding latency, e.g., indexing options or dynamic stuff in your PS1; (3) unusual filesystem stuff, e.g., your home directory is mounted over NFS. If you're in linux and it is reproducible, run strace against a bash launch, and ctrl+c it when it gets stuck. Have a look at the recent system calls.
- portlander12345 9y ago
  This is on Mac OS. I might try the tracing idea though.
chubot 9y ago
I don't have this experience -- I highly suspect NFS or another network file system. On my system, hitting Ctrl-Shift-T inside xterm is almost instant, and that starts a bash process. Likewise for Ctrl-B C in tmux. Bash's startup files are annoying, but you can probably pinpoint the problem with strace. Or maybe try running: strace bash vs. strace bash --norc --rcfile=/dev/null However this isn't the full story because bash's startup sequence is a nightmare and neither of those is likely to be exactly what happens when you're starting a new shell.
brown9-2 9y ago
An easy way to figure this out is to add `set -x` to .bash_profile or its equivalent.

gnachman 9y ago

iTerm2 author here. I'll spend some time looking into iTerm2's latency. I'm sure there are some low-hanging fruit here. But there have also been a handful of complaints that latency was too low—when you hit return at the shell prompt, the next frame drawn should include the next shell prompt, not the cursor on the next line before the new shell prompt has been read. So it's tricky to get right, especially considering how slow macOS's text drawing is. If I could draw a whole frame in a reasonable amount of time, this problem would be much easier! But I can't. Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. The deprecated core graphics API is significantly faster, but it does a not-so-great job at anything but ASCII text, doesn't support ligatures, etc. Using layers helps on some machines and hurts on others. You also lose the ability to blur the contents behind the window, which is very popular. It also introduces a lot of bugs—layers on macOS are not as fully baked as they are on iOS. So this doesn't seem like a productive avenue. How is Terminal.app as fast as it is? I don't know for sure. I do know that they ditched NSScrollView. They glued some NSScrollers onto a custom NSView subclass and (presumably) copy-pasted a bunch of scrolling inertia logic into their own code. AFAICT that's the main difference between Terminal and iTerm2, but it's just not feasible for a third-party developer to do.

nneonneo 9y ago
What text rendering approach does Terminal.app use, then? Is it also some custom thing? Maybe it does its own font caching - given that the terminal uses fixed-size fonts with simple fonts (fixed-width, no kerning, ligatures, etc.), it seems quite believable that they would avoid the overhead of CoreText (which has to handle a LOT more font complexity). With regards to the shell prompt, I'm almost positive that Terminal.app is using some heuristic to read the prompt after a <return>. A little experiment with a tunable spinloop and a fake prompt in C suggests that Terminal.app waits for about 1ms after a return character before updating the screen: a delay of 950us produces an "instant" prompt, while a delay of 1050us shows the cursor at the start of the next line. As the article notes, a 1ms delay is not really noticeable, and that kind of delay only has to happen in a handful of situations.
- gnachman 9y ago

chuckdries 9y ago

I'm surprised Hyper did as well as it did on the latency test, after all it does run in Electron, which I'd expect to add a lot of overhead between keypress and text display

Tyriar 9y ago
You should expect latency similar to a web app in Chrome, just that this has a backing pty processing the input and output.

nneonneo 9y ago

I think one thing that this really points out is just how much care Apple has poured into Terminal.app. It's very good, and every time I have to use another terminal application (ugh conhost.exe) I am reminded of this. It's got a bunch of really thoughtful little features (showing what processes are attached to the current pty, option-clicking to move the cursor rapidly, full mouse support for apps like vim, good linewrap detection, and recently support for rich-text copy/paste which is useful for showing coloured terminal output, etc. etc.), and it remains really fast and snappy despite these features. On a related note, I am big into latency analysis and driving down latency in interactive systems. I'm quite familiar with the touchscreen work cited at the top, and having played with the system I can attest that <1ms latency feels actually magical. At that level, it really doesn't feel like any touchscreen you've ever used - it genuinely feels like a physical object you're dragging around (the first demo of the system only let you drag a little rectangle around a projected screen). It's amazing what they had to do to get the latency down - a custom DLP projector with hacked firmware that could only display a little square at a specified position at thousands of FPS, a custom touchscreen controller, and a direct line between the two. No OS, no windowing system, nada. After seeing that demo, I can't help but believe that latency is the one thing that will make or break virtual reality - the one thing that separates "virtual" from "reality". I want to build a demo someday that does the latency trick in VR - a custom rig that displays ultra-simple geometry that has sub-millisecond latency to human head movement. I will bet that even simple geometry will feel more realistic than the most complex scene at 90 FPS.

vortico 9y ago
>On a related note, I am big into latency analysis and driving down latency in interactive systems. I'm afraid there aren't many of us that care about the subtle details of interaction that mean the most to one's experience. Working in audio, I know the difference between hitting a button and hearing a sound 40ms afterwards, and 4ms afterwords. I would much prefer to use the 4ms, even if it means sacrificing half of the system's features. I feel like such a product will never reach the market, because the market will think they need lots of features, which results in a sacrifice of latency and other UI consistencies. There's always some developer writing the weakest link of an otherwise perfect system. For example, the CPU/GPU hardware, kernel, and browser's accelerated rendering are all engineered with millions of man-hours to be as blazingly fast as possible, and then a web developer comes along and puts a single setInterval() call in their online game or something, and all the optimization benefit goes to the trash. Or, because animation is a trend in UI design right now, developers purposely put in hundreds of milliseconds of delay between common actions like minimizing windows, switching desktops, scrolling, opening/closing apps on mobile, etc. Basically in order for your dream of true virtual reality to be achieved, the principles and respect for low latency has to be maintained across the whole system's stack, especially the higher-level parts.

tome 9y ago

How can st be so slow? It's tiny and hardly does anything!

wmf 9y ago
Maybe it's doing hardly anything one character at a time.
carlesfe 9y ago
Because it's running inside XQuartz on macOS. There is another line on the graph, "linux-st" with much better results.

chillee 9y ago

One other thing to note is that compositors seem to add a fairly large amount of latency. I ran the app linked in the "Typing with Pleasure" post and I saw a roughly ~20ms improvement across various text editors with the compositor turned off (I'm using Termite with Compton as my compositor). http://imgur.com/0G3qbpr http://imgur.com/0G3qbpr

mrob 9y ago

The common LibVTE-based terminals have problems with latency because they're deliberately capped at 40fps. Xterm doesn't have this problem. Gedit gained this problem when it switched to GTK3. The forced animation for scrolling doesn't help. Mousepad still has low latency, at least in the version included with Debian Unstable, but I worry that port of XFCE to GTK3 will make it as bad as GNOME.

chubot 9y ago

If you care about end-to-end latency, I highly recommend this talk by John Carmack: https://www.youtube.com/watch?v=lHLpKzUxjGk https://www.youtube.com/watch?v=lHLpKzUxjGk This talk blew my mind and made me feel like a terrible engineer. He's talking about end-to-end latency in VR, which actually has a commercial motivation because VR products with high latency will make you sick. (this obviously doesn't happen with shells and terminals!) He's talking about the buffering and filtering at every step of the way. And it's not just software -- sensors have their own controllers to do filtering, which requires buffering, before your OS kernel can even SEE the the first byte, let alone user space. On the other side, display devices and audio output devices also do nontrivial processing after you've sent them your data. It's an integrated hardware/software problem and Carmack is great at explaining it! It's a dense, long-ish talk, but worth it.

Tyriar 9y ago

I work on the VS Code terminal/xterm.js[1]. Hyper which currently uses a fork of hterm, is in the process of moving over to xterm.js due to the feature/performance improvements we've made over the past 12 months. Hyper's 100% CPU/crash issue[2] for example should be fixed through some clever management of the buffer and minimizing changing the DOM when the viewport will completely change on the next frame. I'd love to see the same set of tests on Hyper after they adopt xterm.js and/or on VS Code's terminal. Related: I'm currently in the process of reducing xterm.js' memory consumption[3] in order to support truecolor without a big memory hit. [1]: https://github.com/sourcelair/xterm.js https://github.com/sourcelair/xterm.js [2]: https://github.com/zeit/hyper/issues/94 https://github.com/zeit/hyper/issues/94 [3]: https://github.com/sourcelair/xterm.js/issues/791 https://github.com/sourcelair/xterm.js/issues/791

cat199 9y ago

So, on the other side, anyone want to build a true 'terminal emulator' that has baud-speed emulation? top just doesn't look the same without the changes trickling down the screen, matrix like.. Thankfully I can run GlassTTY font connected to the KVM serial console for a near approximation.. but it's still too fast :) Grew up in the VC/GUI transition era, but buying a vt220 and running it at 19200 on a used Vax taught me a Zen of command line that nothing else could... Not only did you have to think about what the command would do, but also how much text it would display, and whether you'd need to reboot the terminal after it got hosed up...

angus-g 9y ago
You could use cool-retro-term[0] for the visual side, but that doesn't support baud rate emulation either. Maybe you could pipe things through `pv` with the `-L` flag to limit speed? [0]: https://github.com/Swordfish90/cool-retro-term https://github.com/Swordfish90/cool-retro-term
acuozzo 9y ago
> So, on the other side, anyone want to build a true 'terminal emulator' that has baud-speed emulation? So this isn't exactly the same, but I improved my Vim muscle memory considerably by running the MS-DOS version of Vim inside of DOSBox, reducing its speed of emulation to the lowest option, and finding the most efficient ways to edit files at a decent pace by making use of the best command sequences possible at any given point in time.

chubot 9y ago

How did he actually measure the latency in this article? Doesn't measuring keypresses to display latency require special hardware? All tests were done on a dual core 2.6GHz 13” Mid-2014 Macbook pro. The machine has 16GB of RAM and a 2560x1600 screen. The OS X version was 10.12.5. Some tests were done in Linux (Lubuntu 16.04) to get a comparison between macOS and Linux. 10k keypresses were for each latency measurements. Latency measurements were done with the . key and throughput was done with default base32 output, which is all plain ASCII text. This is significant. For example, terminal.app appears to slow down when outputting non-latin unicode characters.

adekok 9y ago

Latency is why I could never use a WYSIWYG word processor. While I don't like VI that much, it's latency is low enough that it's not a problem. i.e. I press a key, and miracle of miracles, the character appears on the screen. Using a WYSIWYG word processor, there's enough latency between keypress and visual update that I find them impossible to use. When Apple came out with Pages, it was apparent that they paid strong attention to latency. That means the latency is small enough that (for me) using it isn't an exercise in frustration.

copperx 9y ago
Mellel is a word processor app with lower latency than Pages.
glitch003 9y ago
> I press a key, and miracle of miracles, the character appears on the screen. As long as you press "i" first! :)

iClaudiusX 9y ago

I found this note in the appendix interesting with respect to why we don't seem to notice this latency > Terminals were fullscreened before running tests. This affects test results, and resizing the terminal windows can and does significantly change performance (e.g., it’s possible to get hyper to be slower than iterm2 by changing the window size while holding everything else constant). Perhaps we don't notice because it's so much lower at window sizes much less than fullscreen?

tomsmeding 9y ago

> even the three year old hand-me-down laptop I’m using has 16GB of RAM > on my old and now quite low-end laptop Trust me, that's not a low-end laptop. Either that has the shittiest cpu ever and a terribly mismatched amount of memory, or the author's view of that is high-end or low-end is skewed; in either case, what's low-end nowadays would be ≤4GB RAM. 16GB is LOTS, useful for developers that run large builds and/or VM's regularly. I very much like the rest of the article though, would love to see some latency improvements here and there!

arghwhat 9y ago
It may very well be your view that is skewed. For user-facing terminals/workstations, I would consider ≤8GB low-end ("unusable"). 16GB would be mid-low ("usable"), 32GB would be mid-high ("comfortable"), ≥64GB would be high ("good"). For servers, ≤64GB is low-end, ≥512GB being high-end. That 8GB would be considered low-end does not mean that no one uses it, though. Some people might still rock 2GB laptops, or use the original 256MB Pi 1 as a light desktop.
- tomsmeding 9y ago
  Apparently that's true then. I'm in the Netherlands, so maybe the US is different in this regard. Thanks for clearing up!
  - 59nadir 9y ago
    No, you're completely right in that 16 GB RAM is not considered low-end. You only have to browse for laptops for about 2 minutes to discover that 16 isn't at all "low-end".
    - arghwhat 9y ago
      I think you missed the point I was trying to make entirely (that people's definitions of "low end" differ, although "low-end" steadily moves up), but from that perspective: - 8GB is easily available and what most cheap laptops sport, - 16GB is either default or an addon for cheaper laptops, - 32GB is a premium that is not always available, and - 64GB is usually only available in huge workstation or gamer "laptops", although there are some decent-size Dells with it. While those are not my choice of metrics, they do seem to support the "low", "mid-low", "mid-high" and "high" labels I personally added. At most, you could argue that ≤8GB is low, 16GB is mid and ≥32GB is high. 10 years ago, 16GB would have been high-end for a laptop, but no more.

wallstquant 9y ago

It would also be great to see how these scale with terminal size. I personally use iterm2 but after switching to a new Macbook pro this year with two 5k displays it's noticeably slower. I'm assuming some O(n^2) scaling behind the scenes but I haven't measured anything myself. Still, @gnachman I love your term especially with terminalplots.jl and drawing Julia repl images inline.

victorhooi 9y ago

I want to try Alacritty on OSX - but the big turnoff for me is the lack of binaries. However, I don't know if that's intentional, because they don't think it's ready yet for people who won't install/compile the whole Rust stack from scratch?

steveklabnik 9y ago
> Precompiled binaries will eventually be made available on supported platforms. This is minimally blocked on a stable config format. For now, Alacritty must be built from source. https://github.com/jwilm/alacritty#about https://github.com/jwilm/alacritty#about