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

Performance Matters (2019)

hillelwayne.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: Performance Matters (2019)

#51

Post by throwaway_pdp09 »

ajnin wrote: post #42
pjkundert wrote: post #2

Software can be bad in arbitrary way, and still be useful and not too agonizing. But, software that ignores, delays or discards user inputs ? Absolutely F*$#ing Unacceptable. Unfortunately, most user-interface software (including the ePCR software described in this article) commits this "Unpardonable Sin" of UI software. So, the EMTs, being insulted by the software developer, just don't use it. If you write UI softwa…

Unfortunately Firefox is guilty of that Unpardonable Sin. Often I will open a new window to search for something and start typing my request right away, since the address/search bar should be focused on new windows. If the window takes a little bit of time to appear for some reason, the first few characters will be dropped. Frustrating. Chrome on the other hand does not exhibit this defect, even if I start typing bef…

So it does. Not if you open a new tab, but for a new window (just tried it on palemoon, an FX fork). As I never open a new window, never hit it.

Do a bug report I suggest.

Re: Performance Matters (2019)

#52

Post by noisy_boy »

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

Considering the no. of fields on that form, with that kind of lag, I'll be ditching it too. I mean most of it is check-boxes; just replicate the damn thing on html. Though without knowing more about the setup, I would guess that hardware with terrible input is also involved.

Re: Performance Matters (2019)

#53

Post by Const-me »

unnouinceput wrote: post #19
Const-me wrote: post #7

Earlier quoted context omitted.

> hence I've implemented to only process on frame every second That's merely a workaround, not a fix. Next day someone will use a 8k camera on the same slow tablet. Another day someone will run your app in parallel with with some other process consuming all CPU cores. A fix would be making so that however slow the computer is, processing frames from the camera doesn't affect GUI latency, at least not by much. You pro…

I have bad news for you my friend. Everything is a workaround. You do workaround your family, you do workaround your kids and you do workaround your health. You have seat-belts on your car? Is that a fix or a workaround? Because a fix would be to actually have a car that doesn't crash at all. But would not be economically viable. You have plastic insulator around your electricity wires to prevent you getting electric…

Multithreaded software is all over the place. The process on my PC implementing this browser tab has 38 threads.

For experienced developer using the right tools/architecture it's not even that expensive to develop.

Re: Performance Matters (2019)

#54

Post by ALittleLight »

ajnin wrote: post #42
pjkundert wrote: post #2

Software can be bad in arbitrary way, and still be useful and not too agonizing. But, software that ignores, delays or discards user inputs ? Absolutely F*$#ing Unacceptable. Unfortunately, most user-interface software (including the ePCR software described in this article) commits this "Unpardonable Sin" of UI software. So, the EMTs, being insulted by the software developer, just don't use it. If you write UI softwa…

Unfortunately Firefox is guilty of that Unpardonable Sin. Often I will open a new window to search for something and start typing my request right away, since the address/search bar should be focused on new windows. If the window takes a little bit of time to appear for some reason, the first few characters will be dropped. Frustrating. Chrome on the other hand does not exhibit this defect, even if I start typing bef…

I find the autocomplete in jira constantly doing absolutely preposterous things - e.g. I'll be typing out a query like "project != TheirProject" and, when I've finished typing "TheirProject" and hit enter, jira has just barely managed to raise an autocomplete prompt such that "TheirProject", which is correctly spelled, gets "autocompleted" to something like "!=" making my entire query "project != !=". I have no idea what's happening in this case as autocomplete seems to take a completed correct term and turn it to something that isn't even semantically valid. It happens to me in some variety at least once a day.

Re: Performance Matters (2019)

#55

Post by MagnumOpus »

mikewarot wrote: post #41
unnouinceput wrote: post #29

Earlier quoted context omitted.

Did you know that when they first implemented electricity they just buried them pinned with nails on wood, no insulation? Back then insulating wires was more expensive than just eating energy losses via running current. Like I said, it all comes down to economics.

I'd really like to see evidence of this... if you bury wires directly, the voltage will speed corrosion to the point you won't have wires after a few weeks at best.

Buried them behind drywall and ceilings, not in dirt.

Look up https://en.wikipedia.org/wiki/Knob-and-tube_wiring that is in some cases operational even after a century.

Re: Performance Matters (2019)

#56

Post by MaxBarraclough »

A slight nitpick:

> The ambulance I shadowed had an ePCR. Nobody used it. I talked to the EMTs about this, and they said nobody they knew used it either. Lack of training? No, we all got trained. Crippling bugs? No, it worked fine. Paper was good enough? No, the ePCR was much better than paper PCRs in almost every way. It just had one problem: it was too slow.

That is a crippling bug. The UI is a soft real-time system, [0] and it's doing such a poor job of meeting its deadlines that the user considers the system to be unusable.

If you're writing an autopilot system, it's not enough for the system to eventually make the right decision, it must arrive at the right decision before the deadline. Failure to do so would by definition qualify as a bug.

> Most of us aren’t writing critical software. But this isn’t critical software, either: nobody will suddenly die if it breaks.

Won't they? If the software corrupts the patient data, someone could die, right? Elsewhere the article essentially says as much:

> An error might waste valuable time as nurses chase invisible problems or ignore obvious ones. Worst case, it leads to the wrong treatment. In emergency situations these mistakes can be fatal.

[0] https://en.wikipedia.org/wiki/Real-time_computing#Soft

edit I see brundolf's comment already makes some of these points

Re: Performance Matters (2019)

#57

Post by MaxBarraclough »

obviouslynotme wrote: post #12

I'm old enough to remember Win32 programming in C/C++ because it was the only thing that worked. There was a problem though. Memory management, shitty standard library, and a non-existent packaging system. Java came around and gave you something that worked. Memory management? The runtime does it. Want to do X? Here is a library for X. These combined with academia moving over to Java killed new C++ development hard.…

> The GC just wasn't that good yet.

Also last-minute loading and verification of classes. Interpretation overhead and JIT compilation wouldn't help either, especially on a single-core machine. Many aspects of Java make more sense for servers than for desktop UIs. (This might finally be changing, with recent progress on ahead-of-time compilation of Java without requiring an obscure proprietary JVM.)

Re: Performance Matters (2019)

#58

Post by jspash »

MaxBarraclough wrote: post #56

A slight nitpick: > The ambulance I shadowed had an ePCR. Nobody used it. I talked to the EMTs about this, and they said nobody they knew used it either. Lack of training? No, we all got trained. Crippling bugs? No, it worked fine. Paper was good enough? No, the ePCR was much better than paper PCRs in almost every way. It just had one problem: it was too slow. That is a crippling bug. The UI is a soft real-time syste…

I would argue that the 250ms lag mentioned in the article was not the reason the ePCR system was perceived as being slow.

Consider the new trend in login forms these days whereby you are forced to enter you username or email THEN press a button THEN enter your password THEN press another button. What used to be simple is now no longer simple. Why is it like this? To accommodate the x% of people who seem to get confused in some manner when presented with "too many choices". I forget the reasoning now, and disagree 1000% but don't want to sidetrack my argument any further.

Anyhow... compare the original form to an imagined GUI since we're not presented with the software to make a proper comparison. If you needed to fill out the paper form quickly you can tick..tick...tick..tick..write a bit.tick...tick..read..write.etc.

Now with the software, does it use a mouse? Probably not. It's most likely a touch screen. Possibly a tablet. So now every choice required more interaction. More choices. Opening a dropdown? So you mean to say the developers have decided to hide important information until you request it? The paper version has everything you ever need to know at a glance. One side of a sheet, no need to even flip it over.

This is all conjecture, but I experience this type of thing all the time when a software "solution" comes to fix a real-world "problem". It can be done well. Most UK Govt websites are incredibly well-done IMHO. But usually they're not.

Re: Performance Matters (2019)

#59

Post by phkahler »

jspash wrote: post #58
MaxBarraclough wrote: post #56

A slight nitpick: > The ambulance I shadowed had an ePCR. Nobody used it. I talked to the EMTs about this, and they said nobody they knew used it either. Lack of training? No, we all got trained. Crippling bugs? No, it worked fine. Paper was good enough? No, the ePCR was much better than paper PCRs in almost every way. It just had one problem: it was too slow. That is a crippling bug. The UI is a soft real-time syste…

I would argue that the 250ms lag mentioned in the article was not the reason the ePCR system was perceived as being slow. Consider the new trend in login forms these days whereby you are forced to enter you username or email THEN press a button THEN enter your password THEN press another button. What used to be simple is now no longer simple. Why is it like this? To accommodate the x% of people who seem to get confus…

What you describe is very common. The best example I can think of is a map app with pinch zoom vs an old one with pan and zoom buttons. People want to interact with data, not fiddle with UI controls, menus, and popups. The best UI looks like no UI.

Re: Performance Matters (2019)

#60

Post by TeMPOraL »

jspash wrote: post #58
MaxBarraclough wrote: post #56

A slight nitpick: > The ambulance I shadowed had an ePCR. Nobody used it. I talked to the EMTs about this, and they said nobody they knew used it either. Lack of training? No, we all got trained. Crippling bugs? No, it worked fine. Paper was good enough? No, the ePCR was much better than paper PCRs in almost every way. It just had one problem: it was too slow. That is a crippling bug. The UI is a soft real-time syste…

I would argue that the 250ms lag mentioned in the article was not the reason the ePCR system was perceived as being slow. Consider the new trend in login forms these days whereby you are forced to enter you username or email THEN press a button THEN enter your password THEN press another button. What used to be simple is now no longer simple. Why is it like this? To accommodate the x% of people who seem to get confus…

> Why is it like this? To accommodate the x% of people who seem to get confused in some manner when presented with "too many choices".

FWIW, this is done to accommodate SSO (single sign-on), which matters for any software that's going to be used in corporate or governmental environments. You have to submit your login first, because it's used to determine what authentication method and provider to select.

That said, I hate this flow too, and there must be a better way. It also doesn't excuse products that do not support SSO that still implement such split flow anyway.

Post reply on HN