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

21–30 of 75 posts

Re: Performance Matters (2019)

#21

Post by unnouinceput »

NicoJuicy wrote: post #10
unnouinceput wrote: post #4

Of course performance always matter. Also testing your software under real usability also helps understand the performance. Story time: I got hit by performance these very days. The app I'm developing for one of my clients has to process images from an USB camera. Under my development everything is dandy. Works like a charm, images gets processed and when the user hits the on-screen button that image gets stored in d…

Are you seperating the ui thread from your processing thread?

Not on this app. Also the tablet in question is single core processor so implementing multi-thread is actually even worse. As a detail I left out on above story, this is one of the first surface tablets running Windows 10. I mean it needs W10 because security update reasons, but it was not designed to run such a demanding OS. And then comes my app that requires even more processing power of an already filled up to the guts hardware. Hence the breaks on demanding too much processing.

Re: Performance Matters (2019)

#22

Post by JshWright »

"If 0.1% of PCRs have mistakes that waste an hour of a doctor’s time, that’s 30,000 doctor-hours not spent on other patients."

There is a 0.0% chance that this happens (in my opinion as a paramedic). If I had to guess, 0.1% is probably the rough order of magnitude of the frequency with which doctors look at the PCR at all. We give a verbal report which covers the important details. I would be hard-pressed to come up with an error that could possibly waste an hour of someone's time.

"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? ... It could have saved the person the EMTs couldn’t get to because they lose an hour a week from extra PCR overhead."

Similarly, no. There is no situation in EMS where 250ms is the difference between life and death. It's not like the tones drop for a call and we say 'gee, I wish I could go help that person, but I still have this chart to write...'.

Performance absolutely matters (ironically, I'm a software developer for an EMR at my day job), but a little lag in an ePCR isn't going to kill anyone.

Re: Performance Matters (2019)

#23

Post by charliebreslau »

hansvm wrote: post #17
sim_card_map wrote: post #11

Earlier quoted context omitted.

Or because we created languages like Python that are 10x slower than compiled languages and write code bases with millions of lines of code in them.

It's 10x slower at a lot of things, but even vanilla cpython is every bit as compiled as something like C#. Python is slow because of an extraordinary amount of runtime dynamism, because it doesn't have a JIT or many optimization passes, and because performance isn't a top concern of the project.

Higher abstraction -> less bugs. Forget low level, I beg you.

Re: Performance Matters (2019)

#24

Post by hxtk »

JshWright wrote: post #22

"If 0.1% of PCRs have mistakes that waste an hour of a doctor’s time, that’s 30,000 doctor-hours not spent on other patients." There is a 0.0% chance that this happens (in my opinion as a paramedic). If I had to guess, 0.1% is probably the rough order of magnitude of the frequency with which doctors look at the PCR at all. We give a verbal report which covers the important details. I would be hard-pressed to come up…

> There is no situation in EMS where 250ms is the difference between life and death. It's not like the tones drop for a call and we say 'gee, I wish I could go help that person, but I still have this chart to write...'.

That wasn't how I read it. I may be incorrect, but my interpretation was that the 250ms didn't make the software too slow to be effective but rather too slow to be user friendly.

The idea isn't that it directly killed people by being slow, but rather that it was not adopted because people didn't like using it, and on the paper alternative, mistakes were made that would have been impossible to make on the computer.

Re: Performance Matters (2019)

#25

Post by bsder »

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

> Memory leaks are honestly not even a problem unless you have long running servers.

Firefox is a counterexample to this statement.

Rust appeared because experienced Firefox developers simply couldn't manage C memory manually, C memory with garbage collection, C++ memory manually, or C++ memory with garbage collection.

Re: Performance Matters (2019)

#26

Post by austincheney »

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…

As a front-end developer my professional experience tells me that in practice the ONLY (cannot stress this enough) thing that matters is developer convenience in the code. Everything else be damned.

That said if this UI failure was easier for the developers to code, such as no code and download from NPM, then it is most correct even if both the business and end user are both catastrophically harmed immediately.

Re: Performance Matters (2019)

#27

Post by beachy »

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…

> You have plastic insulator around your electricity wires to prevent you getting electric shock. Is that a fix or a workaround? Because a fix would be to actually have continuous current at max 12V as power lines. But that's not economically viable.

Your examples are wanting.

Wires are also insulated to stop them from touching each other, not just to prevent electrocution. A 12V wire touching another can definitely result in sparks and fire. It can even amputate your finger if you bridge with your wedding ring.

In virtually all situations wire needs insulation - it's a feature not a workaround.

Re: Performance Matters (2019)

#28

Post by JshWright »

hxtk wrote: post #24
JshWright wrote: post #22

"If 0.1% of PCRs have mistakes that waste an hour of a doctor’s time, that’s 30,000 doctor-hours not spent on other patients." There is a 0.0% chance that this happens (in my opinion as a paramedic). If I had to guess, 0.1% is probably the rough order of magnitude of the frequency with which doctors look at the PCR at all. We give a verbal report which covers the important details. I would be hard-pressed to come up…

> There is no situation in EMS where 250ms is the difference between life and death. It's not like the tones drop for a call and we say 'gee, I wish I could go help that person, but I still have this chart to write...'. That wasn't how I read it. I may be incorrect, but my interpretation was that the 250ms didn't make the software too slow to be effective but rather too slow to be user friendly. The idea isn't that i…

I don't have a choice about whether I use an ePCR or not, New York State (and, AFAIK, most other states) mandates it.

The only place where PCR errors matter is on the witness stand... The PCR is certainly important, but any critical information is conveyed in a number of redundant ways, and I would be very surprised if there's been a single incidence of a PCR error resulting in a patient's death.

PCRs are not treated with a great deal of trust, nor should they be (I say this as someone who has written thousands of them). We're dealing with incomplete and conflicting information, patients that actively lie (or, more charitably, forget) about their medical history, and in the case of critically sick patients (the ones that are at risk of dying in the first place) I am more focused on the acute management of their condition. No one expects a PCR to be accurate in every detail. That doesn't mean it's useless, but it also means the system expects there to be errors and has redundancies in place to account for that.

Re: Performance Matters (2019)

#29

Post by unnouinceput »

beachy wrote: post #27
unnouinceput wrote: post #19

Earlier quoted context omitted.

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…

> You have plastic insulator around your electricity wires to prevent you getting electric shock. Is that a fix or a workaround? Because a fix would be to actually have continuous current at max 12V as power lines. But that's not economically viable. Your examples are wanting. Wires are also insulated to stop them from touching each other, not just to prevent electrocution. A 12V wire touching another can definitely…

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.

Re: Performance Matters (2019)

#30

Post by rubatuga »

sim_card_map wrote: post #11
liquidify wrote: post #5

In my limited software engineering experience, most things are slow because they are built on other things that are slow. Generally people do not build software from the ground up. They simply reuse endlessly until someone high up gets so frustrated that they demand a complete rebuild. Then we start over by downloading a bunch of libraries and the same process begins again.

Or because we created languages like Python that are 10x slower than compiled languages and write code bases with millions of lines of code in them.

PyPy is actually very fast, ~10x faster than standard python.
Post reply on HN