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

61–70 of 141 posts

Re: Performance Matters

#61

Post by arendtio »

jblow wrote: post #45
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…

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.

I agree. A few years ago, I powered up some old 166 MHz Windows 95 PC and was surprised how fast it was (certainly not on all tasks, but in general).

Re: Performance Matters

#62

Post by dahart »

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…

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.

To me it seems like Knuth's comment is taken out of context more often than not. He wasn't trying to give people a free pass to make things as slow as possible and ignore system performance. He was assuming that you're making reasonable choices, and not doing overtly stupid things like running the inner loop of your screen drawing in Python, just because it's easy. People always seem to forget the 2nd sentence of the premature optimization quote too: "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%."

Re: Performance Matters

#64

Post by Faark »

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…

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 years ago. Because the tradeoffs are just not worth it. At the same time, stories like the article are a necessary reminder of there being worth in performance.

Re: Performance Matters

#65

Post by mark-r »

gameswithgo wrote: post #16
ecpottinger wrote: post #2

I use to use Amiga computers, I presently use Haiku - i am not trying to say those are the best OSes. But when I use Windows I am surprise how slow some functions are. Worse, I can use two different programs in Windows and one will be dog-slow compared to the other. I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there wer…

It isn't just management. Most software ecosystems (Rust, C, c++ excluded) discourage any thinking about or tinkering with performance knowledge. You see evidence of this on stackoverflow questions, questions on reddit and twitter. Young people or new programmers curious about the fastest way to do things are always lectured about how this is not good to do. It is quite unfortunate because building some experience fo…

I have often found that doing things efficiently isn't really harder than doing them slow. So why not aim for software that's reasonably performant from the start? Sure you can micro-optimize to get every last nanosecond, but that's not what I'm talking about.

Re: Performance Matters

#66

Post by dahart »

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…

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 compute we can put in between input and response.

Maybe the worst systems are getting worse, but I think on the whole responsiveness has been monotonically improving since the invention of the microchip.

> the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over.

I don't know every system ever made, but I don't think there was any long period of time when application software on digital computers controlled the electron beam in a CRT directly or polled keyboard resistances directly, those were abstracted by the hardware via DACs & buffers more or less from the start. Maybe some of the old vector display video games did, I'm not certain, but in any case, it's been abstracted that way for more than 30 years. The first framebuffers happened almost 70 years ago, before 1950.

Re: Performance Matters

#67

Post by psychrometer »

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…

According to the about section of his blog, he is in Chicago.

https://hillelwayne.com/about/

Re: Performance Matters

#68

Post by Jwarder »

JshWright wrote: post #56
Jwarder wrote: post #49

Earlier quoted context omitted.

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

NEMSIS is ugly, but it is vastly easier to work with than HL7. That was an evil XML standard.

Re: Performance Matters

#69

Post by Gene_Parmesan »

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

"Premature optimization is the root of all evil" is incomplete without the surrounding context, and people unfortunately take it to mean "never worry about how efficient your code is," which is not at all what Knuth intended.

Re: Performance Matters

#70

Post by ben509 »

whistlerbrk wrote: post #10

As a former EMT and someone who built their own software to create run reports, I'm a bit skeptical as to that being the only reason. Paper can be edited, even after the point at which you given a carbon copy to a hospital, if you're friendly enough. This probably doesn't happen often or at all but there is a psychological safety there. People make small mistakes all the time on the ambulance in the rush to get them…

That's a good insight. Never dealt with any medical stuff, but I dealt with paperwork in the military as it was going through a (long painful) transition to electronic documents back in the '00s.

And I don't think it's just that society is litigous, but that databases actually (mostly?) work in terms of enforcing the rules you give them.

One anecdote of how things changed was that you used to be able to arrive on post, and if you didn't like your orders, talk to a sergeant major of another unit and quietly get your orders changed, which no doubt drove PERSCOM crazy.

When things were done with paper, there was a certain degree of flexibility in the rules that gave people some amount of local autonomy. When those rules are enforced by a computer, there's much less possibility of someone being able to override the rules when it makes sense.

Normal human social interaction tends to create unwritten rules that are simply more flexible and realistic than the rules we're willing or able to write down.

Post reply on HN