5 ms·

A really basic test is just type "base64 < /dev/urandom" in your terminal. How fast does the screen update? And if you press ctrl+C, how long does it take to

A really basic test is just type "base64 < /dev/urandom" in your terminal. How fast does the screen update? And if you press ctrl+C, how long does it take to get your shell prompt back? (ofc the differences might not be something you ever notice or care about)

mattbee 5y ago
e.g. for me on Windows 11, Wezterm updates slower than both cmd.exe and Windows Terminal. It feels like about 300-400ms to give me control back when I hit ctrl+C. Windows Terminal must be about 100-200ms, cmd.exe maybe a tiny bit slower. I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.
- dogma1138 5y ago
  The new terminal in windows 11 has GPU acceleration. Tho control character latency likely doesn’t have anything to do with the responsiveness that GPU text rendering provides, since ctrl+c is a sequence captured by the OS it’s more likely to have something to do with which ever API the terminal uses to capture input or even the OS itself since I guess the OS still captures the sequence first then has some checks if the object can be universally copied and if not passes the sequence to the active window in focus for it to handle that.
usrbinbash 5y ago
But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?
- nix23 5y ago
  > But what's the use case for this? telnet towel.blinkenlights.nl
- joseluis 5y ago
  well... come to the future: https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
  - usrbinbash 5y ago
    And what exactly is the use case for this? If I want to work with images, animations, etc. I use a GUI library. These in turn already use hardware accelerated rendering. And I already have powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side; the DESKTOP ENVIRONMENT.
    - filmor 5y ago
      Please be aware that all uppercase comes across as quite aggressive. Writing a lot of data to a terminal can happen accidentally or by having an application running that throws out a burst of log messages. In both cases, you'll want to have your terminal to be responsive again as soon as possible and you want it to be light on your cpu s.t. it doesn't interrupt other applications.
      - usrbinbash 5y ago
        > In both cases, you'll want to have your terminal to be responsive again as soon as possible. My terminal emulator doesn't become unresponsive just because the renderer cannot keep up. It still processes input, so if I accidentially cat some-linux-distro-1of4.iso ...I can still Ctrl-C it and stop the process. > it doesn't interrupt other applications. It can't do that anyway in an environment that does preemptive multitasking.
    - southerntofu 5y ago
      > And what exactly is the use case for this? Terminal User Interfaces. There's technically no reason i can't check out an image in a folder when i'm browsing on an SSH session (yes i know i can rsync/scp && xdg-open but it's not exactly as fast to type as viu [0]. > powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side If you have tested and reliable desktop environments to recommend, i'm all ears. All the ones i've tried over the years have their own quirks and memory leaks (yes, that includes GNOME and KDE). But as you said, both approaches are complementary. I'm glad notcurses exists and works via graceful degradation, so people with a modern terminal can get the best while others can still get a featureful ncurses-like experience. [0] https://github.com/atanunq/viu https://github.com/atanunq/viu
- ohgodplsno 5y ago
  What about when you don't know that it ends up being megabytes ? Say you're running Gradle on a large project that does a full recompilation. You don't really particularly care, you know that module X has warnings, etc. But it still prints it all out by default. With carriage returns to update the current percentage, ANSI codes and more. Any millisecond that you spend blocking on outputting your terminal is time that your build can't take. This is compounded by other factors, but ultimately, writing to the terminal is not an asynchronous thing, so your process _will_ be impacted by it being slow.
  - usrbinbash 5y ago
    >Any millisecond that you spend blocking on outputting your terminal is time that your build can't take. Many Build tools don't just pipe the output of every program to their own STDOUT, but redirect them to a logger, which usually runs asyncronously, so from the PoV of the compiler, its output is processed without delay. Secondly, if I know that the build produces a huge amount of output, I redirect it to a file instead. If I don't know the first time, I interrupt, correct my command and re-build.
- wffurr 5y ago
  Android logs.

mattbee 5y ago

e.g. for me on Windows 11, Wezterm updates slower than both cmd.exe and Windows Terminal. It feels like about 300-400ms to give me control back when I hit ctrl+C. Windows Terminal must be about 100-200ms, cmd.exe maybe a tiny bit slower. I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.

dogma1138 5y ago
The new terminal in windows 11 has GPU acceleration. Tho control character latency likely doesn’t have anything to do with the responsiveness that GPU text rendering provides, since ctrl+c is a sequence captured by the OS it’s more likely to have something to do with which ever API the terminal uses to capture input or even the OS itself since I guess the OS still captures the sequence first then has some checks if the object can be universally copied and if not passes the sequence to the active window in focus for it to handle that.

usrbinbash 5y ago

But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?

nix23 5y ago
> But what's the use case for this? telnet towel.blinkenlights.nl
joseluis 5y ago
well... come to the future: https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
- usrbinbash 5y ago
  And what exactly is the use case for this? If I want to work with images, animations, etc. I use a GUI library. These in turn already use hardware accelerated rendering. And I already have powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side; the DESKTOP ENVIRONMENT.
  - filmor 5y ago
    Please be aware that all uppercase comes across as quite aggressive. Writing a lot of data to a terminal can happen accidentally or by having an application running that throws out a burst of log messages. In both cases, you'll want to have your terminal to be responsive again as soon as possible and you want it to be light on your cpu s.t. it doesn't interrupt other applications.
    - usrbinbash 5y ago
      > In both cases, you'll want to have your terminal to be responsive again as soon as possible. My terminal emulator doesn't become unresponsive just because the renderer cannot keep up. It still processes input, so if I accidentially cat some-linux-distro-1of4.iso ...I can still Ctrl-C it and stop the process. > it doesn't interrupt other applications. It can't do that anyway in an environment that does preemptive multitasking.
  - southerntofu 5y ago
    > And what exactly is the use case for this? Terminal User Interfaces. There's technically no reason i can't check out an image in a folder when i'm browsing on an SSH session (yes i know i can rsync/scp && xdg-open but it's not exactly as fast to type as viu [0]. > powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side If you have tested and reliable desktop environments to recommend, i'm all ears. All the ones i've tried over the years have their own quirks and memory leaks (yes, that includes GNOME and KDE). But as you said, both approaches are complementary. I'm glad notcurses exists and works via graceful degradation, so people with a modern terminal can get the best while others can still get a featureful ncurses-like experience. [0] https://github.com/atanunq/viu https://github.com/atanunq/viu
ohgodplsno 5y ago
What about when you don't know that it ends up being megabytes ? Say you're running Gradle on a large project that does a full recompilation. You don't really particularly care, you know that module X has warnings, etc. But it still prints it all out by default. With carriage returns to update the current percentage, ANSI codes and more. Any millisecond that you spend blocking on outputting your terminal is time that your build can't take. This is compounded by other factors, but ultimately, writing to the terminal is not an asynchronous thing, so your process _will_ be impacted by it being slow.
- usrbinbash 5y ago
  >Any millisecond that you spend blocking on outputting your terminal is time that your build can't take. Many Build tools don't just pipe the output of every program to their own STDOUT, but redirect them to a logger, which usually runs asyncronously, so from the PoV of the compiler, its output is processed without delay. Secondly, if I know that the build produces a huge amount of output, I redirect it to a file instead. If I don't know the first time, I interrupt, correct my command and re-build.
wffurr 5y ago
Android logs.