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

91–100 of 141 posts

Re: Performance Matters

#91

Post by smacktoward »

zentiggr wrote: post #90

Sounds like this PCR software should be structured around letting the operator enter information almost as freeform as possible, basically collecting timestamped notes that are reviewed and formalized afterward. UI up front can be very fast capture, with asynch layer to parse and formalize constructs, with a third stage of prefilling the final form (if paper layout needs to be maintained etc) and allowing very flexib…

It'd be even better if, say, your insurance card had your basic medical info stored on it in some encrypted form, and then the EMTs could just scan the card and have half the form populated with accurate information automatically. Or if it just stored some kind of UID that the PCR system could use to pull that information from the insurance company's database.

Re: Performance Matters

#92

Post by bananocurrency »

JshWright wrote: post #60
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...

I feel the same about my EKG. What's a quarter second when it comes to measuring a heart? Who cares about precision.

Re: Performance Matters

#93

Post by bmurphy1976 »

renox wrote: post #71
jblow wrote: post #45

Earlier quoted context omitted.

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.

And Amiga had no memory protection which means that it would be very unsafe to use Internet with it. That said BeOS was quite responsive and had memory protection, but still inadequate security for modern security attacks.

The memory protection doesn't account for the performance hit. It's all the layers of shitty software and garbage devices on top.

Re: Performance Matters

#94

Post by JshWright »

bananocurrency wrote: post #92
JshWright wrote: post #60

Earlier quoted context omitted.

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

I feel the same about my EKG. What's a quarter second when it comes to measuring a heart? Who cares about precision.

A quarter of a second in measurement resolution of an EKG is huge. An extra quarter of a second interpreting or documenting that EKG couldn't be any more meaningless.

Re: Performance Matters

#95

Post by tabtab »

tabtab wrote: post #50
mcguire wrote: post #38

Earlier quoted context omitted.

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

Correction: "let's hear it" instead of "let's here it". Modnays.

Re: Performance Matters

#96

Post by cookiecaper »

rossdavidh wrote: post #74
dahart wrote: post #62

Earlier quoted context omitted.

The point here is not to optimize prematurely, the point is to make responsiveness a design requirement, because it is. You haven't even built it in the first place if it takes more that 100ms to provide any visible feedback to a user input, and you can't even start optimizing until you're already meeting requirements. Once you meet requirements, then by all means pick and choose your optimization battles carefully.…

Sure, but to know that the critical 3% is, you typically need to first build it, and then measure it. Only in rare cases is it so blindingly obvious that the part you are working on will be in the critical 3%; nearly always, you need to actually measure first. To be able to measure, you must first build.

The key component you're missing here is the role of performance in overall design and architecture.

If responsiveness is a goal, as it should be in any GUI but especially must be in a system intended for use in medical emergencies, there are high-level decisions that can be made to keep things in the right ballpark. One of these decisions may be "the interface should never have to wait for a network response", for example.

The process of micro-optimizing specific segments of program code still needs to depend on actual benchmarks and measurements, but the value of reasonable and experienced system architecture that considers the actual requirements of the problem domain cannot be overstated. You're sunk from the get-go if you make the wrong tradeoffs here.

Unfortunately, the industry is mostly populated by clowns who are just blistering to get the hottest buzzword listed on their resume, very frequently rising up to the point of blatant professional misconduct. This leads to many truly absurdist design decisions that sink projects long before the first chunk of code goes into production.

Re: Performance Matters

#97

Post by api »

"Premature optimization is the root of all evil" is one of those programming sayings that's very often misunderstood.

It does not mean that performance doesn't matter or that you shouldn't think about performance.

What it means is two things:

(1) It's usually a waste of time to tinker with small optimizations until you've made things work and until you've profiled.

(2) Don't compromise your design or write unmaintainable code out of premature concern over performance.

The second is the more important and subtile meaning. It means don't let concern for performance hobble your thinking about a problem.

Re: Performance Matters

#98

Post by pbreit »

JshWright wrote: post #54

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

Sounds like you are saying similar/same thing.

Re: Performance Matters

#99

Post by mntmoss »

dahart wrote: post #66
Faark wrote: post #64

Earlier quoted context omitted.

On the other hand, the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. Today's systems are complicated, and we try to hide that complexity behind abstractions. All of those with buffers. Input buffers, OS message buffers, tripple image buffers, and so on. All of it adding time. Yes, we won't again have the responsiveness we had 30 y…

There's unnecessary complexity and abstractions -- especially in poorly designed systems, yes, that's part of my point, so I agree there. > we won't again have the responsiveness we had 30 years ago. Not sure I can agree with that. For the best systems, we absolutely have better responsiveness now than we've ever had, shorter latencies now in the hundreds sometimes thousands of hertz, and orders of magnitude more com…

The raw throughputs are definitely better but there is concern regarding latency even at the lowest levels, since today's CPUs have complex cache, power state and frequency throttling mechanisms. You cannot guarantee that something will perform with identical runtime in all expected use-cases unless you take care to use hardware that is optimized in that direction. And because the software environments are more complex a lot of capability is just dropped on the floor because the intermediate layers get in the way.

W/R to buffers in front of things, a decent number of the micro systems of the 70's were so memory starved that they would make these tradeoffs to retain video sync - that describes the Atari 2600("racing the beam" is the name of a book about the console), and Cinematronics vector games(if it did not complete drawing at 60hz, it reset). Most early arcade games did work with DACs(or rather ADCs) but ran their own calibration and button debounce code - and even with layers of abstraction that's still basically true today.

With graphics, the move towards desktop environments doing GPU compositing impacts graphics coders, since they now often have window manager buffers in front of them instead of direct access to a rectangle of pixels.

Web browsers are a more extreme example of this. Because the graphics model revolves around document presentation, things that aren't really documents, or are extremely customized documents, often get burdened by latency that they wouldn't have if it weren't for the browser.

Re: Performance Matters

#100

Post by JshWright »

pbreit wrote: post #98
JshWright wrote: post #54

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

Sounds like you are saying similar/same thing.

We're describing the same outcome. The author is describing a very different cause of that outcome.
Post reply on HN