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

71–80 of 141 posts

Re: Performance Matters

#71

Post by renox »

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.

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.

Re: Performance Matters

#72

Post by hinkley »

phkahler wrote: post #28
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…

>> For example, one common thing you have to do to get performance, is to cache values in multiple places, instead of looking them up every time. This made me cringe. This is filling out a form. It could conceivably be a single record (or small set) in memory that gets committed/updated somewhere else in the background. Overly complicated solutions for simple problems are one of the primary things that kills performa…

I had an overly long conversation where someone was hand wringing about how and when we pull data to populate the list of states and territories of the US (the fact that the address had to be inside the US had legal standing).

I insisted, and probably still do, that since this list hasn’t changed since World War II, odds were really good that the server would reboot before the next change was made, and so looking it up at startup should be just fine.

Re: Performance Matters

#73

Post by rossdavidh »

tibbon wrote: post #43
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…

This isn't premature optimization however. It's having some reasonable SLOs that must be measured throughout development and met. To say that the average button response has to be within 20ms, and the 99% slowest within 50ms is pretty reasonable, and can be measured reasonably easily in a test suite.

Sure. But that implies you make it (without everything optimized for performance), measure it, and then make the things which are slow enough to matter, faster. Which sounds just like avoiding premature optimization.

Re: Performance Matters

#74

Post by rossdavidh »

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

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.

Re: Performance Matters

#76

Post by seanmcdirmid »

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)?

Re: Performance Matters

#77

Post by jodrellblank »

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…

Amiga at least, older computers were more responsive because they did less - directly attached video and keyboard hardware, no USB, no compositing video drivers, less font smoothing, and so on.

See Dan Luu's analysis here: https://danluu.com/input-lag/

and here https://danluu.com/keyboard-latency/

> Moreover, a modern computer with one of the slower keyboards attached can’t possibly be as responsive as a quick machine from the 70s or 80s because the keyboard alone is slower than the entire response pipeline of some older computers.

Haiku (BeOS) was always promoted on its native multithreading and responsive UI, with early demonstrations showing windows being dragged around while playing video, IIRC, it's impressive that it still holds to that.

But it also says a bit about what software people pay for and keep using - if sluggish Windows software has thrived, and BeOS crashed and burned. And then on Windows and Linux, light fast software gives way to bloaty huge sluggish software left and right.

Re: Performance Matters

#78

Post by novok »

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…

You can make apps with complicated, animated UIs that respond in 16ms just fine with the hardware of an iPhone 4, which is way past the era of CRTs and direct keyboard polling. We know this because we made those apps 7 years ago.

Performance is always a business decision. Most people don't want to pay for it.

Re: Performance Matters

#79

Post by hinkley »

I have a theory on the dynamic being described, based on my experiences as a software developer.

When you are juggling and prioritizing a list of tasks, they are occupying short term memory. If you can perform the current task from muscle memory, you don’t upset working memory. But as soon as you start having to think about it, and worse once you start editorializing in your head, things start to drop off.

Worst case results of this phenomenon have occurred when you finish a hard task and you have to ask yourself, “what was I doing?/why was I doing this?”

So you want your tools to be unobtrusive. People who love hand tools know this. Somehow we do not.

Re: Performance Matters

#80

Post by dahart »

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.

I can agree with everything you said, but I don’t think there’s really the paradox here or chicken-egg problem that you’re implying. It’s not difficult to make design decisions before building based on the specs of your components. It’s not hard to know that filling pixels via a scripting language or waiting on a synchronous internet request is going to hose your responsiveness. It is possible to make reasonable design decisions before you build, and to reach responsiveness before you optimize. The main reason people fail to reach responsiveness is for lack of making responsiveness an up-front requirement, it’s not for lack of optimization.
Post reply on HN