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

41–50 of 141 posts

Re: Performance Matters

#41

Post by Ensorceled »

phkahler wrote: post #30
Ensorceled wrote: post #21

When I was writing software for medical devices in the '90s, we had a very clear policies for dealing with cognitive drift that included performance ceilings, testing for drift in beta testing, etc. In our testing, 10 seconds was the absolute maximum time that a surgeon could "idle" and stay on task in surgery. In addition, we found that including spinners, progress bars, etc. would not necessarily reduce the cogniti…

>> The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.

Well, we used to have to write our own UI elements and swap them into the top 8 bits of the framebuffer reserved for the overlay.

Re: Performance Matters

#42

Post by mcguire »

hoorayimhelping wrote: post #20
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"?

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…

Ever used one of those product search forms where you click that you want to see products with attribute A, a check appears, you go on to click on attribute B and a check appears there, and then the product list updates showing attribute A with a complete loss of B?

A responsive UI is necessary, but it's not sufficient to make up for a slow back end.

Re: Performance Matters

#43

Post by tibbon »

rossdavidh wrote: post #22

So, interesting and all, but it ignores the main reason for the advice to build it first, then optimize for performance, which is that if you build everything for performance from the beginning, you end up with a lot of code that is optimizing for performance of something that isn't the bottleneck. In other words, performance that doesn't show up in the user's experience, because something else is the main delay. Now…

This isn't premature optimization however. It's having some reasonable SLOs that must be measured throughout development and met. To say that the average button response has to be within 20ms, and the 99% slowest within 50ms is pretty reasonable, and can be measured reasonably easily in a test suite.

Re: Performance Matters

#44

Post by TeMPOraL »

rossdavidh wrote: post #22

So, interesting and all, but it ignores the main reason for the advice to build it first, then optimize for performance, which is that if you build everything for performance from the beginning, you end up with a lot of code that is optimizing for performance of something that isn't the bottleneck. In other words, performance that doesn't show up in the user's experience, because something else is the main delay. Now…

> Instead, what you get is code that is much longer, and more complex, and therefore harder to update, and more likely to be buggy.

I'm gonna repost a chart I made previously[0][1].

  Spectrum of performance:
  LO |---*-------*--------*------------*-------| HI
         ^       ^        ^            ^
         |       |        |            |_root of all evil if premature
         |       |        |_you should be here
         |       |_you can be here if you don't do stupid things
         |_you are here
Tricks like denormalizing your data model ("cache values in multiple places") start somewhere around the "you should be here" point. But in any typical program there's plenty of stuff to be done left of that point, and those things don't make your code more complex or longer. They only require care and willingness from the software vendor.

--

[0] - https://news.ycombinator.com/item?id=20389856

[1] - https://news.ycombinator.com/item?id=20520605

Re: Performance Matters

#45

Post by jblow »

penagwin wrote: post #37
phkahler wrote: post #30

Earlier quoted context omitted.

>> The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.

I don't know the details, but many embedded interfaces/controllers don't have very fast processors/microcontrollers and UI is really expensive compared to everything else it has to do (take some inputs, and submit some data). Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be. EDIT…

The Amiga 500 was pretty responsive, and its CPU power was epsilon compared to a Raspberry Pi or any modern embedded system.

It's just that modern software is garbage. That's all.

Re: Performance Matters

#46

Post by ambicapter »

penagwin wrote: post #37
phkahler wrote: post #30

Earlier quoted context omitted.

>> The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.

I don't know the details, but many embedded interfaces/controllers don't have very fast processors/microcontrollers and UI is really expensive compared to everything else it has to do (take some inputs, and submit some data). Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be. EDIT…

Don't think it really matters, if your device can display a dropdown, then it can display an empty dropdown and load entries within a couple seconds.

Re: Performance Matters

#47

Post by arendtio »

My first tablet was kinda slow. At least slow enough that when it got too old, I wondered if I even wanted to buy another tablet, because I rarely used the first one.

Then I bought a new one, which was faster and more responsive and my tablet usage completely changed ;-)

So I can personally testify that performance is a most relevant part of the user experience.

Re: Performance Matters

#48

Post by TeMPOraL »

tibbon wrote: post #40

I saw this myself in an ambulance in the Boston area. The PCR system they were using was on some Toughbook-style computer, and I could tell that it was lagging and slow to input basic stuff on. Apparently whoever had put it together cared more about durability (important) than performance. Or maybe it worked great when it was deployed, but the newer software updates weren't built for such a slow machine. They used it…

Or maybe they made some stupid decisions like making each update query something over the Internet, which works fine when testing, but not when you're on the streets, in close proximity to a lot of other cellular Internet users.

Re: Performance Matters

#49

Post by Jwarder »

mfer wrote: post #33

Something is missing in this conversation. Do the people who are creating the applications that deal with medical data have motivation to make it better or more useful? I've spoken with numerous people in my life who deal with these types of systems. Everyone complains. Fields for information are in unexpected places. There are too many things to click on. All of the people I've talked with agree on the same things.…

I worked on EMS data entry software for a while (deepest apologies to any EMTs reading) and the big issue we ran into was needing to fulfill doctor/administrator pet projects to get a sale.

The county wants to collect data on if a drowning incident happened at a pool without a locking gate. Now all services need to update their software to include a random checkbox. An EMT was caught without gloves and now the parent hospital wants EMTs to record what levels of PPE they wear on every run. The customer might get a grant if they can help track infectious diseases so now there is an extra box where the EMT can guess if the patient has the flu.

In the abstract that is good data to want to know, but it ends up being more junk on the screen for the EMT to skip over while dealing with the patient or sitting in the hospital parking lot after a run.

Re: Performance Matters

#50

Post by tabtab »

mcguire wrote: post #38
tabtab wrote: post #27

Quote: It wasn’t even that slow. Something like a quarter-second lag when you opened a dropdown or clicked a button. But it made things so unpleasant that nobody wanted to touch it. I'm skeptical that's the reason they didn't use it unless it's a high-volume application. Like everything in IT, it depends. A high-volume app definitely needs attention to response and performance because employees will be wasting tons o…

I'm sorry; are you saying that electronic patient care reports are not a "high volume application", that they should be "desktop client-server applications," or that the statements by the users about why they don't use the system should be disregarded?

I don't have the usage & programming labor stats to make a definitive statement on that particular application including the size of the org using it. My main point was that "it depends" and should be subject to further tradeoff and business analysis rather than "X is always bad".

A quarter-second lag does not sound like a significant problem to me, and may require a lot of IT funds to remove. Often such is only justified if it's a high-use application. Would you agree that 100 hours of extra programming to save 50 hours of data entry time is usually not worth it (all else being equal)? If so, let's start there and slice into further factors.

Please don't give me bad scores for trying to be logical and rational, people! Resources are limited, orgs have to spend with care. Sure, it's nice job security for us IT people if orgs spend big bucks to make all apps snappy, but from a business and/or accounting standpoint, it could be the wrong decision. You view the world different when your money is on the line.

If you know a way to make all apps cheap, good, AND snappy at the same time, let's here it! I'm all Vulcan ears.

Note that one can make web apps snappy, but there are often maintenance and/or creation time tradeoffs for doing such. A few well-run shops do it well, but most shops are average-run.

Post reply on HN