Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance Matters

hillelwayne.com

Post reply on HN
Print view View original

11–20 of 141 posts

Re: Performance Matters

#11

Post by BubRoss »

ziddoap wrote: post #7
ChrisSD wrote: post #3

> Something like a quarter-second lag when you opened a dropdown or clicked a button So the title would more accurately be "UI responsiveness matters"? I doubt anyone would think this kind of lag doesn't matter. It sounds like the software was designed (and tested) for better hardware than it is running on, or at least different hardware. But that's just a guess.

Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?

Responsiveness is about latency and feedback. Performance could mean that or it could mean throughput. If I'm using an interface I want responsive feedback without latency above everything else.

I know it's easy to dump on electron, so I will. Multiple electron apps, especially the ethereum client, are the worst programs I have ever used, because there is enormous lag on a computer that runs everything else flawlessly. It's so bad it can't even be all blamed on electron, but more than bloat or memory use, interactivity is what I consider the most important factor in an interface. I even put it above great design or intuitiveness. I would take blender's ridiculous interface choices over something better that lags like the ethereum client any day of the week.

Re: Performance Matters

#12

Post by leeoniya »

cogman10 wrote: post #5
ecpottinger wrote: post #2

I use to use Amiga computers, I presently use Haiku - i am not trying to say those are the best OSes. But when I use Windows I am surprise how slow some functions are. Worse, I can use two different programs in Windows and one will be dog-slow compared to the other. I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there wer…

At least at my work, the issue is twofold. First, nobody measures performance. If they do, it is often done poorly (without using performance tools) Second, when performance is a problem, everyone guesses on the cause. Remember how they don't measure? Well, they also will say things like "this is probably slow because of X" where X is the database, the network, a method they hate, etc. Performance analysis requires a…

this sounds terrifying.

thankfully at my work nothing goes into production without a performance eval measured at least by Lighthouse & webpagetest on Fast 3G/2015 mobile/chrome.

it's nice to be able to dictate these requirements ;)

Re: Performance Matters

#13

Post by viraptor »

0xDEFC0DE wrote: post #9
ziddoap wrote: post #7

Earlier quoted context omitted.

Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?

My take is that responsiveness has a cap of speed that’s pinned to human perception. Once you get here you can stop worrying about needing more. Performance does work as fast as possible regardless. You always want more but you’re capped by the system, hardware, and algorithms and not human perception. Feels like I’m splitting hairs though

No, that's a very good split :-)

Even when responsiveness is great, you can still work on performance to improve: resources utilisation, energy usage, jitter of responsiveness, etc. Users may not notice, but the spending account may do. This distinction is more relevant with multi-user or time sharing systems, less so with single-user game consoles. (If you're hitting the right framerate at the most demanding scenes, why bother?)

Re: Performance Matters

#14

Post by snaky »

ziddoap wrote: post #7
ChrisSD wrote: post #3

> Something like a quarter-second lag when you opened a dropdown or clicked a button So the title would more accurately be "UI responsiveness matters"? I doubt anyone would think this kind of lag doesn't matter. It sounds like the software was designed (and tested) for better hardware than it is running on, or at least different hardware. But that's just a guess.

Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?

Performance is about how it works, responsiveness is all about how it feels.

Re: Performance Matters

#15

Post by Crinus »

ecpottinger wrote: post #2

I use to use Amiga computers, I presently use Haiku - i am not trying to say those are the best OSes. But when I use Windows I am surprise how slow some functions are. Worse, I can use two different programs in Windows and one will be dog-slow compared to the other. I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there wer…

The Windows vs Haiku case you describe is mainly a difference in terms of development culture. In Windows you can get similar fast performance and responsiveness by using the native GUI functionality, but most desktop applications nowadays use toolkits like Qt (at best) or Electron (at worst) that reimplement a ton of functionality that the OS itself already provides and treat it as something different than what it really is.

On the other hand in Haiku everything uses the native Haiku APIs.

But from what i've seen ever since Qt and Java were ported to Haiku, a bunch of applications started relying on those to run on it instead of using the native APIs (which IMO defeats the entire point of Haiku).

Haiku does use a lot of prewritten libraries BTW, they're just hidden behind the scenes and shared among applications instead of each one bringing their own copy.

Re: Performance Matters

#16

Post by gameswithgo »

ecpottinger wrote: post #2

I use to use Amiga computers, I presently use Haiku - i am not trying to say those are the best OSes. But when I use Windows I am surprise how slow some functions are. Worse, I can use two different programs in Windows and one will be dog-slow compared to the other. I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there wer…

It isn't just management. Most software ecosystems (Rust, C, c++ excluded) discourage any thinking about or tinkering with performance knowledge. You see evidence of this on stackoverflow questions, questions on reddit and twitter. Young people or new programmers curious about the fastest way to do things are always lectured about how this is not good to do. It is quite unfortunate because building some experience for how to do things fast is very useful. It isn't always correct to optimize the hell out of things, of course, but we should encourage the curiosity behind it, so that more of us have the tools to do it when it is correct to do so.

Re: Performance Matters

#17

Post by juliangoldsmith »

ChrisSD wrote: post #8
ziddoap wrote: post #7

Earlier quoted context omitted.

Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?

Because that's literally the complaint as given. If the UI had reacted "instantly" it would be more user friendly. Even if the performance of the (non UI) code was slower. EDIT: Or to put it another way: "perceived performance can be more important than actual performance".

Responsiveness is a result of adequate performance. The dropdowns that the article refers to are probably populated by a database, as opposed to being static. It doesn't matter if the dropdown opens instantly, what matters is that the information it contains is available.

Re: Performance Matters

#18

Post by alkonaut »

ziddoap wrote: post #7
ChrisSD wrote: post #3

> Something like a quarter-second lag when you opened a dropdown or clicked a button So the title would more accurately be "UI responsiveness matters"? I doubt anyone would think this kind of lag doesn't matter. It sounds like the software was designed (and tested) for better hardware than it is running on, or at least different hardware. But that's just a guess.

Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?

If I click a button and it instantly shows me a dialog with a progress bar, and the progress bar progresses smoothly for one hour to complete the task, that is responsive (the UI responds to my click and the background update as quick as anyone could desire).

That the task takes an hour to complete may or may not indicate a problem with performance.

The fact that the task shows a progress bar at all is likely because at some point the task would complete synchronously and without a progress bar in say 10 seconds or 60 minutes. In that case, the programmer mistake was to allow the problematic performance of the program affect the responsiveness of the program.

So a progress bar is used when the performance can't be easily fixed but the program must be responsive.

Re: Performance Matters

#19

Post by shay_ker »

Did that quarter-second lag kill anyone? Was there someone who wouldn’t have died if the ePCR was just a little bit faster, fast enough to be usable? And the people who built it: did they ask the same questions? Did they say “premature optimization is bad” and not think about performance until it was too late? Did they decide another feature for the client was more important than making the existing features faster? Did they even think about performance at all?

This seems like a lot of imagining of scenarios that may or may not have happened. Perhaps another way of looking at this is - did the company hired to build this actually care whether EMTs used their software, or were they looking to get a paycheck?

So many health tech firms fall in the latter bucket. Such is the reality of the business - with huge enterprise sales funnels and hospital networks that don't understand the value of UX & great product (and caring a lot about their bottom line), this result isn't unexpected.

Re: Performance Matters

#20

Post by hoorayimhelping »

ziddoap wrote: post #7
ChrisSD wrote: post #3

> Something like a quarter-second lag when you opened a dropdown or clicked a button So the title would more accurately be "UI responsiveness matters"? I doubt anyone would think this kind of lag doesn't matter. It sounds like the software was designed (and tested) for better hardware than it is running on, or at least different hardware. But that's just a guess.

Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?

You can make a UI feel responsive even if the underlying system is not performant.

Let's say you have a client app with checkbox that toggles some boolean variable that communicates with a server. If you're on a 3g connection in an ambulance, it might take a few seconds to send that request to the server and get a response back.

An unresponsive UI would sit there and make you wait for the request/response to complete. You click the checkbox, then nothing happens, then suddenly, some time later, the checkbox is checked and the page refreshes, or a state change happens. It's jarring and weird. A responsive UI would update the state of the app based on the user's actions even if the request hasn't completed yet.

Tightly related to this the concept of optimistic UIs - the UI acts optimistically and updates the state of the app under the assumption that server-backed state changes will work. The iPhone's messages app sending messages is the prototypical optimistic UI interaction. You send a message, the blue / green speech bubble shows up on your messages app while the message is in flight. If it succeeds, nothing changes and you're none the wiser. If it fails, you get an option to delete the message or resend.

Post reply on HN