1. 50

  2. 17

    I wish this much thought was given to millisecond-level input lag more often. I can’t be the only person who makes decisions about apps and websites based on this simple metric. Little details like Personal Capital’s iOS app needing to finish it’s startup login animation before presenting me with TouchID, the sluggish input of Electron apps, etc. drive me nuts.

    Sure, there were frequent BSODs, hard freezes, etc. back in the 90s/00s, but I don’t remember feeling like every single program I used felt “spongy” like they do today. Things felt snappy and responsive.

    1. 15

      “Software is getting slower faster than hardware is getting faster.” - Niklaus Wirth

      1. 7

        Input buffering was also better back in the day. I would frequently type ahead of slow programs, confident that all my characters would eventually end up on screen. I do not have that confidence any more.

        1. 6

          I consider anything without a working input buffer completely broken. There’s nothing more infuriating than a computer that’s slower than a human and requires the human to back off and retry.

        2. 4

          I still think that Mac OS 7 was pretty much the perfect system. Yeah, yeah, no memory protection, no pre-emptive multitasking; but for sheer [em]getting shit done[/em] it was so much less clunky and [em]gluey[/em] than modern systems.

          1. 3

            Sometimes, it does feel like we have traded all the different types of crashes for a generally slower world.

            1. 4

              If that’s really the trade-off that was made, then it might’ve actually been worthwhile.

              1. 1

                I don’t know about that. I do think it’s nice that we can develop things faster now. But shouldn’t we then modularize them so we can make a more efficient implementation of the more critical parts? GitHub started doing this with Atom, but as of this writing it’s nothing more than a toy project.

                In essence, I don’t believe we have to choose between fast development cycles and having any efficiency whatsoever. I think if we actually plan it out carefully—rather than relying on hype-driven development—we can write our software quickly & messily in a dynamic/scripting language, and have it work right away; but then slowly start making it more efficient.

              2. 2

                I think we’re traded hardlocks for softlocks. I don’t think we’ve notably improved crashes/faults overall.

                • hardlock = crash and burn, computer locks up.
                • softlock = page fails to load in browser. “I’m sorry please try again later”. Even better: “logic bugs”, including when pages/features don’t work because they have been misplaced in the latest update.

                A lot of this comes from moving to higher level frameworks (native software) and platforms (web browsers).

            2. 13

              About 15 years ago, I used Windows and had never used Linux. When I needed Linux, I ssh’d via Putty (a small and fast SSH client for Windows).

              My first thought when switching to Ubuntu desktop was: “why is the terminal so slow?” The keys felt spongy. It was pretty incredible that network latency + Putty-to-kernel latency was less than Ubuntu’s terminal-to-kernel latency.

              Now that I think of it, it matches Carmack’s observation that you can send a packet to Europe faster than most systems (app + OS + hardware) can draw a pixel ? I forget the exact quote, but he was talking about why latency in VR is important.

              Anyway, I’ve never used WSL, but Windows never breaks compatibility, so maybe they are using the same low level Windows APIs that Putty did 15 years ago (and probably still does, since I doubt it’s changed much.)

              1. 11

                you can send a packet to Europe faster than most systems (app + OS + hardware) can draw a pixel

                I was skeptical at first, so I did some checking. According to Wolfram Alpha it would take light (in fiber) about 44ms to travel from Los Angeles to Berlin in a direct path. I pinged a bunch of the top .de domains, and averaged all the ones that didn’t give me faster than lightspeed (and therefore impossible) results. The average was 150ms roundtrip (accuracy +/- 5ms). That means a packet would take around 75ms one way.

                According to this random blog post with cool tables, that number checks out. With a notable exception of Apple products (especially the iPad Pro + Pencil), devices generally have higher roundtrip display latency than one-way packets from LA to Europe. Some even have higher display latency than roundtrip packets to Europe.

                That’s kinda sad :(

                1. 4

                  Yeah I think it’s well documented… not just John Carmack, but Dan Luu have also made this comparison. And my former boss has done such end-to-end latency experiments.

                  FWIW I’m pretty sure the Carmack video is this one:


                  It’s very good, but also very dense. IIRC this is the one talking about latency in VR. You can get away with high latency on desktop and mobile systems, but in VR, it makes the users sick.

                2. 8

                  WSL doesn’t have its own terminal. It uses conhost, the same as cmd.exe and plain powershell.exe use (PowerShell ISE uses a different one).

                  1. 4

                    When did you switch to Linux? It hasn’t always been that way. Both xterm and Eterm were pretty fast on fvwm on my Pentium II. Somewhere in the next decade, everything started to slow down, even though computers got faster. It would be fine if there were more features added, or the software was less buggy, but every 5 years it seems the wheel gets reinvented by whomever is holding the keys.

                    1. 2

                      This was around 2005 or so, maybe with Ubuntu Hardy. I wouldn’t be surprised if it were especially bad on Ubuntu at that time.

                      I still use Ubuntu, and I wouldn’t say I have a problem with terminal latency.

                      On the one hand, I think browsers add more latency than terminals, and I type a fair bit in browsers now (like right now :) ). So the terminal probably feels fast by comparison.

                      On the other hand, when I switch to a virtual terminal (Ctrl-Alt-F1), I definitely notice the latency difference. So it’s not solved, but it’s perhaps not a pressing issue …

                      1. 1

                        I think another issue is network latency – I do so much work over ssh that the terminal latency seems small in comparison.

                      2. 1

                        If I were to guess, I think xterm and similar apps always used the legacy X11 bitmapped fonts. New terminals on the other hand use true type fonts. It probably makes no difference on modern systems these days but maybe it did 10 years ago.

                        1. 1

                          I don’t know how true type fonts work under the hood. Do they re-render every character every time, or is the resulting bitmap cached?

                      3. 1

                        They pretty much said they were using those low-level API’s. They’re the ones I used long, long ago. Good to see they’re still supported. I’ll use them again if possible if I do a Windows app. Course, we have fancier languages now that can improve usability and safety. Maybe. :)

                        1. 1

                          I think ubuntu comes with the very heavy gnome-terminal. Try xterm, or a gpu-accelerated terminal like kitty or alacritty.

                        2. 4

                          This is very interesting. Just for fun, I fired up ubuntu.exe and started playing with it. Unfortunately, the terminal seems glitchy with tmux, drawing lines of text in the wrong spot from time to time. So maybe it’s a bit faster, but it’s not really usable for me.

                          1. 1

                            I’ve noticed the same problem using tmux under WSL (Ubuntu). Hopefully they’re still working on terminal compatibility and correctness.

                          2. 3

                            This is so true. I spent this autumn in fluxbox, for exactly this reason. Really it does all the things that I like in modern systems, but so much more snappy. For exactly the same bloat reasons that we all swear over.

                            1. 2

                              vscode terminal but w/ WSL shell is actually p fast on Windows.