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

81–90 of 141 posts

Re: Performance Matters

#81

Post by qudat »

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

There's not much room for competition because the level of rules and regulations required to enter the market are very high. Basically the only companies that can manage that red-tape are massive corporations. The end result is a system like Epic that can do everything. These monoliths are usually large, difficult to change, and riddled with tech debt. Creating user stories for the thousands of different things that an administrator/physician/nurse/patient can do in these systems is seemingly an insurmountable task. I wouldn't want to try to rebuild a software system like Epic and I absolutely would not want to work on a system like that.

Furthermore, Epic is sold to administrators, not physicians. It checks all the boxes so it gets the contract.

Re: Performance Matters

#82

Post by tcxgy »

dahart wrote: post #51
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…

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…

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

Windows XP on a Pentium 4 was snappier than Windows 10 is on an i7 today.

Re: Performance Matters

#83

Post by elevation »

I'm can't dispute that fast software is a desirable trait for users. I would love to spec low latencies into the requirements documents for my GUI projects. But from a business standpoint, UI latency requirements are a good way to sabotage a project.

Slow solutions have a dramatic business advantage: using libraries, you can shave months off your delivery schedule by adding miliseconds to your UI delays. The months add up; so do the miliseconds. By using someone else's crufty libraries, you can write a calculator app over the weekend. Libraries will handle the double buffering for screen painting, unpacking fonts and rendering them into bitmaps, how to reflow text onto a screen, etc. It might take seconds for the app to load all it's assets and display the first user activity, but it was cheap to create, easy to iterate, and it gets the job done. These are hallmarks of a valuable startup engineering effort.

But the development process for speedy applications is anathema to businesses of any size. You have to throw away Electron and hire systems engineers with knowledge of the entire platform. After some profiling, they may determine that the required speed is only possible once the system event handler has been replaced with a pared down routine, or when the framework's audio interface is bypassed so the sound card can be accessed through low-latency DMA mode. You have to repeat this for every platform you intend to support. You have to throw away the wheel that everyone else is using and pay to reinvent one that spins a little faster.

To paraphrase Joel Spolsky's comment on rewriting software: are you sure you want to give that kind of a gift to your competitor? For most companies it isn't worth it.

Are there exceptions? Yes: a motivated engineer like John Carmack may work months to eliminate another 3ms frame latency out of a VR headset simply because of personal passion. Google can amortize additional billions by wringing 100ms out of page load times by funding a browser project so complex that you also have to design a new build system for it. But if you're not Carmack and you're not Google, you probably can't afford to reinvent the wheel.

Re: Performance Matters

#84

Post by kirkil1 »

dahart wrote: post #51
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…

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…

My raspberry pi 3 cannot do that even with all driver blobs installed plus a cooler. That internet lie has to stop, many people buy these devices just to be amazed at how bad they are for what they intended them to be in their household. They definitely have many applications, but multimedia is not one of them.

Re: Performance Matters

#85

Post by JshWright »

seanmcdirmid wrote: post #76
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…

Wouldn’t a stylus/tablet interface provide the same benefits of a pen and paper solution for that requirement (well, you could wipe down the stylus, maybe chucking it is extreme)?

Not really. You still have to handle the tablet, and it's just more of a hassle to interact with (a piece of paper is a lot less fragile). A stylus will just get lost within the first day (we use laptops that in theory have a stylus, but I've never actually seen one... just an empty hole in the side of the laptop).

Re: Performance Matters

#86

Post by [deleted] »

elevation wrote: post #83

I'm can't dispute that fast software is a desirable trait for users. I would love to spec low latencies into the requirements documents for my GUI projects. But from a business standpoint, UI latency requirements are a good way to sabotage a project. Slow solutions have a dramatic business advantage: using libraries, you can shave months off your delivery schedule by adding miliseconds to your UI delays. The months a…

[deleted]

Re: Performance Matters

#87

Post by anaphor »

Gene_Parmesan wrote: post #69

People who quote "premature optimization is etc." never provide the full quote. The full quote has a significant degree of highly important nuance. > "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about…

Basically it can be summed up to "don't optimize until you've identified the critical paths"

Re: Performance Matters

#88

Post by varjag »

Faark wrote: post #64
dahart wrote: post #51

Earlier quoted context omitted.

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…

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…

I have a distributed networked system on $35 off-the-shelf modules running Linux synced to under 100 microseconds measured deviation.

There is no good technical reason for slow UI elements in 2019.

Re: Performance Matters

#89

Post by jasonlotito »

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…

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

This isn't a question of optimizing something that doesn't need optimizing. It's about making fundamental choices from the beginning that are optimized and won't need to be optimized later.

It's the choice between using native code v.s. electron to build your app. You can make the argument that electron might be better for various reasons, but if you choose to go native, that's an optimization step you are taking.

Basically, you are saying "Premature optimization is the root of all evil" without including the rest of the quote and misreading what Knuth wrote.

> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

There are certain fundamental things you can do, optimization you can do before you ever write the software. This comes from experience.

> Instead, what you get is code that is much longer, and more complex, and therefore harder to update, and more likely to be buggy.

No, this does not have to happen. In fact, if you build it first and worry about optimization later, you're more likely to end up in this state.

> How do you know what spots in the code it's worth it?

Experience. You get that from experience with code. And you can't get that experience if you are frequently changing jobs.

Re: Performance Matters

#90

Post by zentiggr »

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

Last step would be archiving locally and then transmitting to whatever outside system.

Post reply on HN