5 ms·

> That establishes the fact that modern keyboards contribute to the latency bloat we’ve seen over the past forty years Sometimes I try to imagine what things w

> That establishes the fact that modern keyboards contribute to the latency bloat we’ve seen over the past forty years Sometimes I try to imagine what things would be like if people were still trying to optimize their stuff as if it were to be ran on a 16mhz machine with a few kb of ram. Then I get back to the 6 electron apps I gotta work with, where latency between a key showing up in the search box and search results appearing gets close to 10s. Somehow things got wrong somewhere.

cjonas 5y ago
Could be worse. I've been doing dev on a citrix desktop, where a single keypress can take seconds to register.
- rubatuga 5y ago
  Fuck Citrix, fuck RDP
  - AnIdiotOnTheNet 5y ago
    Dude, RDP is amazing. I'll take it any day over the typical *nix alternatives.
  - ComputerGuru 5y ago
    RDP is insanely optimized and there a lot of hard science and math involved in making it work efficiently and effectively for dynamically changing content from steaming media to editing in a terminal and everything in between. However, the technology is constantly updating - if your experience is only with RDP from the days of XP, I can understand your frustration. Also, most third party (non-MSFT) products (servers or clients) don’t implement the full spec and stick to the bare-bones, high-latency, low-throughput v1 protocol which is still RDP thanks to MS dedication to backwards compatibility, and that will absolutely give you a subpar experience as well.
- DaiPlusPlus 5y ago
  > I've been doing dev on a citrix desktop, where a single keypress can take seconds to register. Why would that be slow, though? Citrix would only be like that if you were over a high-latency network connection - that's unavoidable. If it is a LAN connection then the Citrix box is overloaded: add more RAM and processor cores (and disable the page-file: disk IO is a big killer of VDI UX). The problem with the Electron apps mentioned is that it's a reflection of the sad state of affairs that we have crappy UX caused by bad technical decision-making, rather than a crappy UX just because the hardware is underprovisoned.
  - fomine3 5y ago
    Yeah, it's natural that remote desktop is bad in bad connection even if Citrix is well made. But it can be said that adopting VDI over Citrix solution for developer machine is a mistake, something like adopting Electron.
    - DaiPlusPlus 5y ago
      > But it can be said that adopting VDI over Citrix solution for developer machine is a mistake That's debatable - certainly in many cases it makes a lot of sense: e.g. a corporate environment with hot-desking (i.e. Windows Roaming Profiles), but programmer/dev users need a consistent workspace so they can't use roaming profiles, instead having consistent and persisted VDI environment makes sense. Another reason is that you can pre-image and snapshot an entire OS environment more easily (and even more easily if you're using a Hyper-V VDI instead of a multi-user Terminal Services or Citrix VDI) which is great for ensuring everyone on a team has the exact same build/dev/test environment. This is being reinvented as "Code Spaces" which GitHub and Visual Studio seem to be really getting behind: https://github.com/features/codespaces https://github.com/features/codespaces and https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/ https://github.blog/2021-08-11-githubs-engineering-team-move... ----- But I'd wager that most devlop-in-Citrix/TermServ situations are in "normal" corporate businesses with "no fun allowed" IT policies, and even if they don't have a hot-desk office policy they probably still don't like the idea of anyone having root/admin access to their own machines. (I'm fortunate to have never been in that situation in my working life, but I've heard plenty of horror stories from friends who did short-term contract dev work on-site for companies like Tesco and the like)
1--6zVa-E 5y ago
The soy devs gotta go
AussieWog93 5y ago
>Sometimes I try to imagine what things would be like if people were still trying to optimize their stuff as if it were to be ran on a 16mhz machine with a few kb of ram People (mainly EEEs) still do this in the embedded space, where most hardware interaction is done my directly writing to/reading from registers. Latency for most things is on the order of 100ns - 10us, maybe 1ms or so if you're using a particularly slow serial bus.
- LanceH 5y ago
  They need to turn their attention to the pumps at the gas station near me, which seem to be optimized for ear piercing beeps with each key press. I realize the blind may need feedback while they fill up their car, but surely if they can hear well enough to drive they can hear a normal beep.
  - ComputerGuru 5y ago
    All the gas stations near me have been spending all their R&D budget on publishing advertisements. They have loud mini TVs embedded into the pump that you can’t turn off churning out lowest dregs of society crap and ads on full blast while you pump. It’s now a conflict of interest for them to prioritize pump maintenance and upgrades because the faster you finish pumping the less ad money they make.
noir_lord 5y ago
> Somehow things got wrong somewhere. The hardware folks gave us magical exponential growth for a straight 30-50 (depending how you count it) run. That lead to a "we can add more features or we can make it fast" pick one and the business always picks more features. (note: business here just means "non-devs" and can include some devs). We used that amazing hardware to optimise towards delivery speed over everything else (and while we did/do some horrible things - there is no doubt that a modern dev in 2021 commands processing power and vast libraries that would have been a dream to kid me in the 80's) and when every layer of your stack leaves performance on the table that adds up cumulatively. Throw in that on the time scales of computers humans are laughably slow and you can get away with a lot of inefficiency. It's an interesting trade-off - I figure at some point we'll reach the limits of what we actually can do and efficiency will shoot back up the importance chart (in some ways for the hyperscale folks it has for a while, 5% improvement over millions of boxes adds up). Saying it's "lazy devs not optimising" isn't fair though, they are optimising but in other directions.
- AnIdiotOnTheNet 5y ago
  > That lead to a "we can add more features or we can make it fast" pick one and the business always picks more features. Is this really true though? In my estimation the number of features for any given piece of software since the 90s has gone up a little in some cases, down in others (looking at you GNOME), leading to net average of 0. The software with the most gain in features seem to be high end games and AV editing, which also seem to be performing really well because they aren't typically made in electron. What does seem to be true is that developers use frameworks like electron because they believe it saves them a lot of time and their time is more valuable than the user's. Well, that and the rampant complexity fetishism.
  - vlovich123 5y ago
    Performance means having the freedom being able to choose technology stacks along a other axes than performance. Ease of developer use, development speed, debugging, deployment targets, available and market talent are just some other things the business of engineering cares about. So of course engineers may pick Electron because nothing else fits that criteria if you ignore performance. It solves * Cross-platform distribution. An electron app builds off the extensive work Chrome has done supporting the various operating systems (and chromium has ported it to many others). * Democratizes native application development. It’s not gate kept behind needing C++ developers and makes it easier to have JS developers work on it (+ abundance means it’s cheaper for the business) * Speeds up development. There’s no arguing that ReactJS has been a successfully dominant and powerful JS UI toolkit Sure, do I wish there were better, leaner UI toolkits out there? Yes. If the goal however is to enable the far greater pool of web developers to also be able to build desktop apps with the same ease as a website, I don’t know that you could do much better than the Electron model (there’s an interesting one that uses the browser engine installed in the OS instead to lower distribution size, which is more of a “different but same” kind of situation” kind of thing). Qt is trying ball compete but it’s really struggling and Rust and other tech stacks are struggling to compete. They have perf, but are lacking in the “enable large swaths of developers to contribute” piece.
bee_rider 5y ago
I mean, we also have these massive pipelines and reorder buffers nowadays, and pretty good optimizing compilers, so really tuning all-over would be bit of a nightmare and not super rewarding (just tune GEMM kernels if that is your thing).
colechristensen 5y ago
One thing I’ve thought about is having some dev hardware or demo hardware required to be intentionally bottom of the barrel.

cjonas 5y ago

Could be worse. I've been doing dev on a citrix desktop, where a single keypress can take seconds to register.

rubatuga 5y ago
Fuck Citrix, fuck RDP
- AnIdiotOnTheNet 5y ago
  Dude, RDP is amazing. I'll take it any day over the typical *nix alternatives.
- ComputerGuru 5y ago
  RDP is insanely optimized and there a lot of hard science and math involved in making it work efficiently and effectively for dynamically changing content from steaming media to editing in a terminal and everything in between. However, the technology is constantly updating - if your experience is only with RDP from the days of XP, I can understand your frustration. Also, most third party (non-MSFT) products (servers or clients) don’t implement the full spec and stick to the bare-bones, high-latency, low-throughput v1 protocol which is still RDP thanks to MS dedication to backwards compatibility, and that will absolutely give you a subpar experience as well.
DaiPlusPlus 5y ago
> I've been doing dev on a citrix desktop, where a single keypress can take seconds to register. Why would that be slow, though? Citrix would only be like that if you were over a high-latency network connection - that's unavoidable. If it is a LAN connection then the Citrix box is overloaded: add more RAM and processor cores (and disable the page-file: disk IO is a big killer of VDI UX). The problem with the Electron apps mentioned is that it's a reflection of the sad state of affairs that we have crappy UX caused by bad technical decision-making, rather than a crappy UX just because the hardware is underprovisoned.
- fomine3 5y ago
  Yeah, it's natural that remote desktop is bad in bad connection even if Citrix is well made. But it can be said that adopting VDI over Citrix solution for developer machine is a mistake, something like adopting Electron.
  - DaiPlusPlus 5y ago
    > But it can be said that adopting VDI over Citrix solution for developer machine is a mistake That's debatable - certainly in many cases it makes a lot of sense: e.g. a corporate environment with hot-desking (i.e. Windows Roaming Profiles), but programmer/dev users need a consistent workspace so they can't use roaming profiles, instead having consistent and persisted VDI environment makes sense. Another reason is that you can pre-image and snapshot an entire OS environment more easily (and even more easily if you're using a Hyper-V VDI instead of a multi-user Terminal Services or Citrix VDI) which is great for ensuring everyone on a team has the exact same build/dev/test environment. This is being reinvented as "Code Spaces" which GitHub and Visual Studio seem to be really getting behind: https://github.com/features/codespaces https://github.com/features/codespaces and https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/ https://github.blog/2021-08-11-githubs-engineering-team-move... ----- But I'd wager that most devlop-in-Citrix/TermServ situations are in "normal" corporate businesses with "no fun allowed" IT policies, and even if they don't have a hot-desk office policy they probably still don't like the idea of anyone having root/admin access to their own machines. (I'm fortunate to have never been in that situation in my working life, but I've heard plenty of horror stories from friends who did short-term contract dev work on-site for companies like Tesco and the like)

1--6zVa-E 5y ago

The soy devs gotta go

AussieWog93 5y ago

>Sometimes I try to imagine what things would be like if people were still trying to optimize their stuff as if it were to be ran on a 16mhz machine with a few kb of ram People (mainly EEEs) still do this in the embedded space, where most hardware interaction is done my directly writing to/reading from registers. Latency for most things is on the order of 100ns - 10us, maybe 1ms or so if you're using a particularly slow serial bus.

LanceH 5y ago
They need to turn their attention to the pumps at the gas station near me, which seem to be optimized for ear piercing beeps with each key press. I realize the blind may need feedback while they fill up their car, but surely if they can hear well enough to drive they can hear a normal beep.
- ComputerGuru 5y ago
  All the gas stations near me have been spending all their R&D budget on publishing advertisements. They have loud mini TVs embedded into the pump that you can’t turn off churning out lowest dregs of society crap and ads on full blast while you pump. It’s now a conflict of interest for them to prioritize pump maintenance and upgrades because the faster you finish pumping the less ad money they make.

noir_lord 5y ago

> Somehow things got wrong somewhere. The hardware folks gave us magical exponential growth for a straight 30-50 (depending how you count it) run. That lead to a "we can add more features or we can make it fast" pick one and the business always picks more features. (note: business here just means "non-devs" and can include some devs). We used that amazing hardware to optimise towards delivery speed over everything else (and while we did/do some horrible things - there is no doubt that a modern dev in 2021 commands processing power and vast libraries that would have been a dream to kid me in the 80's) and when every layer of your stack leaves performance on the table that adds up cumulatively. Throw in that on the time scales of computers humans are laughably slow and you can get away with a lot of inefficiency. It's an interesting trade-off - I figure at some point we'll reach the limits of what we actually can do and efficiency will shoot back up the importance chart (in some ways for the hyperscale folks it has for a while, 5% improvement over millions of boxes adds up). Saying it's "lazy devs not optimising" isn't fair though, they are optimising but in other directions.

AnIdiotOnTheNet 5y ago
> That lead to a "we can add more features or we can make it fast" pick one and the business always picks more features. Is this really true though? In my estimation the number of features for any given piece of software since the 90s has gone up a little in some cases, down in others (looking at you GNOME), leading to net average of 0. The software with the most gain in features seem to be high end games and AV editing, which also seem to be performing really well because they aren't typically made in electron. What does seem to be true is that developers use frameworks like electron because they believe it saves them a lot of time and their time is more valuable than the user's. Well, that and the rampant complexity fetishism.
- vlovich123 5y ago
  Performance means having the freedom being able to choose technology stacks along a other axes than performance. Ease of developer use, development speed, debugging, deployment targets, available and market talent are just some other things the business of engineering cares about. So of course engineers may pick Electron because nothing else fits that criteria if you ignore performance. It solves * Cross-platform distribution. An electron app builds off the extensive work Chrome has done supporting the various operating systems (and chromium has ported it to many others). * Democratizes native application development. It’s not gate kept behind needing C++ developers and makes it easier to have JS developers work on it (+ abundance means it’s cheaper for the business) * Speeds up development. There’s no arguing that ReactJS has been a successfully dominant and powerful JS UI toolkit Sure, do I wish there were better, leaner UI toolkits out there? Yes. If the goal however is to enable the far greater pool of web developers to also be able to build desktop apps with the same ease as a website, I don’t know that you could do much better than the Electron model (there’s an interesting one that uses the browser engine installed in the OS instead to lower distribution size, which is more of a “different but same” kind of situation” kind of thing). Qt is trying ball compete but it’s really struggling and Rust and other tech stacks are struggling to compete. They have perf, but are lacking in the “enable large swaths of developers to contribute” piece.

bee_rider 5y ago

I mean, we also have these massive pipelines and reorder buffers nowadays, and pretty good optimizing compilers, so really tuning all-over would be bit of a nightmare and not super rewarding (just tune GEMM kernels if that is your thing).

colechristensen 5y ago

One thing I’ve thought about is having some dev hardware or demo hardware required to be intentionally bottom of the barrel.