3 ms·

I think users have a performance budget and once you are inside that budget, there are rapidly diminishing returns for faster speed. > it's obvious that modern

I think users have a performance budget and once you are inside that budget, there are rapidly diminishing returns for faster speed. > it's obvious that modern software will be as slow and inefficient as it possibly can be before normal people notice and complain Thats sort of circular. If people don't complain there's probably better places to spend engineering effort. Besides, the slower speed is traded off for something: a safer abstraction, faster development, features the users are requesting, better security, etc. I think some of us on HN have higher expectations for software performance than "normal" users, so we are the first to complain (or use alternate, faster software).

Narishma 6y ago
That's because "normal" users don't know any better. They don't know what their hardware is capable of, so they don't know that their software is slow, so they don't complain about it. If they do they usually blame hardware.
- userbinator 6y ago
  Unfortunately, from some of the other comments in this discussion, it seems a lot of developers don't know any better either --- they've never seen what real "fast" is, so they think the amount of latency they experience is normal.
  - edeion 6y ago
    I sympathize to your comment... But at the same time I'm likely to be in the crowd of the unknowings. Could you suggest examples or a way to get an idea how fast computers can be. I've recently been amazed when cracking an old cryptanalysis puzzle at what Python can do in very little time. But I have no idea what a responsive OS feels like on a general standpoint. Should I try to compile Firefox on Windows 3.1? (Just kidding on this last one, obviously.)
- boring_twenties 6y ago
  Right. Normal users think things like, "my computer is slow, it must be getting old, time to buy a new one."
- paulie_a 6y ago
  That's because normal users simply don't care nor have a reason to care.
abjKT26nO8 6y ago
Just because an average user isn't able to quite put a finger on their frustration and its source, doesn't mean it isn't there. Studies show that even though users often won't be able to see that it's the performance of the program that is infuriating, they will be more nervous using it anyway and will prefer to use a faster alternative. When phones with touch screens entered the market, we'd often put up with the latency of touch interaction, but these were irritating nevertheless. Then the early iPhones showed how low the latency could be and how much more pleasant using it is. iPhones degraded in this regard since then and Android phones didn't catch up even to the current iPhones. And I'll never use an Android, one of the main reasons being exactly this: latency.
fouric 6y ago
> I think users have a performance budget and once you are inside that budget, there are rapidly diminishing returns for faster speed. "Budget" is kind of a strong word. For non-hard-real-time systems, there are various points of diminishing returns on an exponential curve. However, very few interactive programs I've ever used have ever gotten to an acceptable point on that curve, given their features and the performance of my hardware. Android should not take three seconds to drop down the top drawer on a Snapdragon 617. Flutter should not introduce a noticeable latency for typing ASCII characters. Emacs should not take several seconds to display my which-key bindings. Gmail should not take ten seconds to load. > If people don't complain there's probably better places to spend engineering effort. For the majority of software, what's actually happening is that people don't realize that "better" is even possible. > the slower speed is traded off for something: a safer abstraction, faster development, features the users are requesting, better security, etc. You can make better tradeoffs, and you can make worse tradeoffs. The vast majority of modern software trades off an unacceptably large amount of performance for an unacceptably small amount of all of those things, to the point where those aren't tradeoffs - they're excuses for abysmal engineering discipline. Additionally, most of those tradeoffs aren't actually necessary. Rust gives you speed, memory safety, and some better security all at once. Common Lisp gives you speed, memory safety, better abstractions, and faster development time. The vast majority of features shouldn't actually have a performance penalty if not being used - for instance, if I don't use the "export to PDF" feature in an office suite, there's absolutely no good reason for it to have any performance impact aside from possibly a few milliseconds of startup time. Finally, the vast majority of software slowdowns that I've experienced have had nothing to do with security at all. > I think some of us on HN have higher expectations for software performance than "normal" users Or we're much more aware of what hardware is actually capable of.

Narishma 6y ago

That's because "normal" users don't know any better. They don't know what their hardware is capable of, so they don't know that their software is slow, so they don't complain about it. If they do they usually blame hardware.

userbinator 6y ago
Unfortunately, from some of the other comments in this discussion, it seems a lot of developers don't know any better either --- they've never seen what real "fast" is, so they think the amount of latency they experience is normal.
- edeion 6y ago
  I sympathize to your comment... But at the same time I'm likely to be in the crowd of the unknowings. Could you suggest examples or a way to get an idea how fast computers can be. I've recently been amazed when cracking an old cryptanalysis puzzle at what Python can do in very little time. But I have no idea what a responsive OS feels like on a general standpoint. Should I try to compile Firefox on Windows 3.1? (Just kidding on this last one, obviously.)
boring_twenties 6y ago
Right. Normal users think things like, "my computer is slow, it must be getting old, time to buy a new one."
paulie_a 6y ago
That's because normal users simply don't care nor have a reason to care.

abjKT26nO8 6y ago

Just because an average user isn't able to quite put a finger on their frustration and its source, doesn't mean it isn't there. Studies show that even though users often won't be able to see that it's the performance of the program that is infuriating, they will be more nervous using it anyway and will prefer to use a faster alternative. When phones with touch screens entered the market, we'd often put up with the latency of touch interaction, but these were irritating nevertheless. Then the early iPhones showed how low the latency could be and how much more pleasant using it is. iPhones degraded in this regard since then and Android phones didn't catch up even to the current iPhones. And I'll never use an Android, one of the main reasons being exactly this: latency.

fouric 6y ago

> I think users have a performance budget and once you are inside that budget, there are rapidly diminishing returns for faster speed. "Budget" is kind of a strong word. For non-hard-real-time systems, there are various points of diminishing returns on an exponential curve. However, very few interactive programs I've ever used have ever gotten to an acceptable point on that curve, given their features and the performance of my hardware. Android should not take three seconds to drop down the top drawer on a Snapdragon 617. Flutter should not introduce a noticeable latency for typing ASCII characters. Emacs should not take several seconds to display my which-key bindings. Gmail should not take ten seconds to load. > If people don't complain there's probably better places to spend engineering effort. For the majority of software, what's actually happening is that people don't realize that "better" is even possible. > the slower speed is traded off for something: a safer abstraction, faster development, features the users are requesting, better security, etc. You can make better tradeoffs, and you can make worse tradeoffs. The vast majority of modern software trades off an unacceptably large amount of performance for an unacceptably small amount of all of those things, to the point where those aren't tradeoffs - they're excuses for abysmal engineering discipline. Additionally, most of those tradeoffs aren't actually necessary. Rust gives you speed, memory safety, and some better security all at once. Common Lisp gives you speed, memory safety, better abstractions, and faster development time. The vast majority of features shouldn't actually have a performance penalty if not being used - for instance, if I don't use the "export to PDF" feature in an office suite, there's absolutely no good reason for it to have any performance impact aside from possibly a few milliseconds of startup time. Finally, the vast majority of software slowdowns that I've experienced have had nothing to do with security at all. > I think some of us on HN have higher expectations for software performance than "normal" users Or we're much more aware of what hardware is actually capable of.