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

51–60 of 141 posts

Re: Performance Matters

#51

Post by dahart »

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…

Respectfully, that is a common and tempting argument, but no, no, and no. The raspberry pi 3 has a freaking dual core 64-bit 1.4Ghz processor that is more than fast enough to run full-screen video games at 60Hz.

It's more than just an "optimization" that is making UIs on these plenty-fast processors so slow, it's a large scale failure of software engineering, building slow layers on top of slow layers.

The processor is not the reason for slowness, and we've had absolutely responsive UIs not just 10 years ago, but 50 years ago too. The actual reason is economic: cheap engineering. Using freely available components not well suited to embedded devices, writing layers using scripting languages because it's easy, treating the problem as solved when the functionality is there without regard to the speed.

Re: Performance Matters

#52

Post by stickfigure »

mcguire wrote: post #34
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.

Software like this doesn't get written in someone's garage. There was almost certainly a team behind it, including a dedicated product manager. The product manager made a decision not to prioritize performance.

On one hand, it seems a clear failure. On the other hand, it's hard to judge these kinds of decisions from the outside. The product seems to be successful; the customer paid for it and installed it in ambulances. Maybe if they'd focused on performance instead of adding feature XYZ, or increased the price by adding a faster CPU, the customer would have bought something else. Your competition checks more boxes, therefore must be better!

Mostly when I see shitty software, I think not "who wrote this?" but "who bought this?"

Re: Performance Matters

#53

Post by yoz-y »

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…

Many systems have historically prioritized how nice they look at the expense of speed. First Mac OS X releases were notoriously sluggish for example.

I cringe every time I see a laggy but 'nice' looking interface. I'd rather see a wireframe with just text, it will still be more useful than a button I can never trust.

Re: Performance Matters

#54

Post by JshWright »

Not sure where the author is from, but I'm not aware of any states that still allow paper PCRs. ePCRs are just a fact of life.

I pretty much never bother opening the laptop until I'm at the hospital. There are a lot of reasons for that, but a laggy UX isn't really one of them (despite the fact that the UX is indeed super laggy on any ePCR I've ever used). Instead I use a pen and paper (or a pen and a strip of white medical tape on my thigh, for a more critical patient).

The reason I don't bother is because the whole UI is just too much of a hassle. Not the application frontend, the whole thing. The laptop, the keyboard, etc. With a pen and paper I don't have to keep taking my gloves off and putting new ones on each time I need to switch from documenting something to caring for the patient (a pen is trivial to wipe down, or just toss if needed). With a pen and paper I can jot simple notes in a shorthand I'm familiar with, rather than having to navigate to the right page to enter the information I want to record at the moment.

I know very few providers that bother touching the laptop prior to arrival at the hospital. Generally we write notes on paper, then bring the laptop into the ER and start typing while we we're waiting for a bed for our patient (it's not uncommon that this takes long enough to get the whole chart written). At my agency we have two hours from when we transfer care to when the chart has to be signed off and locked.

I also chuckled at the suggestion that "0.1% of PCRs have errors that waste an hour of a doctor's time". In my experience 0.1% is pretty much how frequently the PCR gets reviewed at all in the ER, and anything important enough to spend an _hour_ on would have been mentioned up front during the transfer of care (nevermind the fact that an hour is an absurd amount of time for a doctor to be spending on a single patient).

Re: Performance Matters

#55

Post by arendtio »

ambicapter wrote: post #46
penagwin wrote: post #37

Earlier quoted context omitted.

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.

I use a Progressive Web App on a Samsung Galaxy S3 smartphone (1GB RAM) on a regular basis. If the phone just got a fresh ROM, rebooted within the last hour and the app is a fresh installation, I have no performance issues what-so-ever (~60 FPS animations, etc.).

But over time things degrade. I don't know why, but every year or so I have to format the internal SD card to keep the OS in shape. If I install too many apps which run in the background the RAM gets crowded and everything starts lagging.

And finally, the app itself is not as optimized as it should be, so that when I use it with the data I enter during a year or so, there are some steps which take a few seconds (rendering a list with >300 items/DOM nodes). By the way, a 'couple of seconds' is unacceptable from a UX perspective.

So this is just one example where you can have a 100% good experience but also a very degraded experience with the same hardware and software, due to different factors (from OS degradation to awful O(n) optimization).

Re: Performance Matters

#56

Post by JshWright »

Jwarder wrote: post #49
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…

If I had a dollar for every time I swore at NEMSIS, I could quit my day job...

Re: Performance Matters

#57

Post by mark-r »

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 had an Epson scanner that had a progress bar while scanning. You could HEAR the scanner progress, and it wasn't close to even - sometimes it would stop for a while, or even back up. It didn't matter though, the progress bar kept an even pace and always finished at the exact instant the scan was done.

That has always stood out as one of the more impressive engineering feats I've seen.

Re: Performance Matters

#58

Post by ben509 »

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…

Given the clueless remarks I see that are invariably followed by, "I work on embedded systems," I suspect there's more bad engineering to blame than deficient hardware.

Re: Performance Matters

#59

Post by TeMPOraL »

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.…

If it's anything like non-critical software, then I'd say the middle layer between developers and users. That is, the sales and management teams on both customer and producer sides. There are many reasons this middle layer might appear and cause problems - lack of trust in developers, need to "protect" company "secrets", software's main utility is checking some boxes on some contract and not actually being useful, etc. But almost everywhere I look this happens.

Re: Performance Matters

#60

Post by JshWright »

shay_ker wrote: post #19

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?…

If someone is sick enough that a "quarter second" matters, there's zero chance the tablet is out in the first place. In reality if a quarter second is enough to kill someone, they're gonna die anyway...
Post reply on HN