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

31–40 of 141 posts

Re: Performance Matters

#31

Post by mcntall »

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…

This is one of the reasons why you will often see software installation look linear [10min until it is finalized, 8min until is finalized...] even though on a micro-scale, the process may be oscillating a lot more.

Re: Performance Matters

#32

Post by xtian »

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…

Most performance problems come from incidental complexity and programming techniques which don't take into account what the actual hardware is doing. Your focus should not be on tactical optimizations like caching but rather on expanding your understanding of the system as a whole in order to devise simpler and more efficient solutions to problems. Look into "data-oriented design" for more info on this.

In the modern business environment, time is most often not allocated for optimization after functionality is complete. And even when it is, if performance is completely ignored throughout the development process, your options for improving it at the end are severely limited.

Re: Performance Matters

#33

Post by mfer »

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.

It's as if no UX people were involved. The experience doesn't fit the need quite right.

What would motivate the makers of these things to improve on the situation? How are the contracts won? Do the people who have to use this stuff have a say in it? Do the hospitals and doctors offices measure stats to see what's working and what's not?

This space is ripe for disruption simply based on user experience.

Re: Performance Matters

#34

Post by mcguire »

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 comment is

1. True.

2. The primary reason that most software is painful to use and occupies significantly more resources than strictly necessary.

Programmers, like everyone else, focus on their own pain spots rather than the issues of others. If you don't at least think about optimizing at first, you won't ever do it.

Re: Performance Matters

#36

Post by grumpy8 »

It's about trade-off. You improve performance at the cost of something else you're not working on. Without the context, it's hard to tell if that cost was justified. I.e. maybe there were 20 critical bugs and the team made the call that perf. was good-enough and it was better to stabilize the software. Most often than not, you can always improve performance and drawing the line is hard.

Re: Performance Matters

#37

Post by penagwin »

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.

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: I have to agree with you guys, even given the tech they had they should've put a higher priority on responsiveness. I don't know what the status is today, but I know even the 2015 Prius's touch screen feels too unresponsive to my liking.

Re: Performance Matters

#38

Post by mcguire »

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?

Re: Performance Matters

#39

Post by penagwin »

mcntall wrote: post #31
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…

This is one of the reasons why you will often see software installation look linear [10min until it is finalized, 8min until is finalized...] even though on a micro-scale, the process may be oscillating a lot more.

I highly doubt most programs know when they'll finish, usually there's multiple stages of say installation, copying files, editing the registry, generating some other files, downloading updates, etc. Some of those stages take milliseconds, others can take minutes or longer. Maybe some take seconds on an NVME SSD but takes 4 minutes on an HDD (verifying files commonly has this behaviour), etc.

If the progress bar doesn't differentiate which stage it's in then it's purpose is mostly just to let the user know it's doing something.

Re: Performance Matters

#40

Post by tibbon »

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; but it was like inputting a data on a slow ATM.
Post reply on HN