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

121–130 of 141 posts

Re: Performance Matters

#121

Post by richardw »

JshWright wrote: post #85
seanmcdirmid wrote: post #76

Earlier quoted context omitted.

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

You can wipe down a tablet but not a pad. Isn't there some risk of transmission via the paper pad?

(Thank you for the insights!)

Re: Performance Matters

#122

Post by novok »

Faark wrote: post #104
novok wrote: post #78

Earlier quoted context omitted.

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.

I admit not having good, hard data. My most vivid related memory is comparing the back then new flat screen to the my CRTs and being disappointed with both delay and sharpness (CRTs exponential decay is way nicer imo). Obviously wouldn't expect those to have gotten worse, though. Anyway, you mentioned phones: 16ms from touch to response on screen? That's hard for me to believe and I'd love to read up on that, if you…

There are other parts of the program beyond touches, such as scroll performance and what you do in reaction to touch events. Also the user doesn't move their finger within 85ms anyway if you think about it. That is moving to tap the phone, smushing their finger into the phone and then moving their finger away from the phone to see the result.

Nowadays you have 120hz scrolling on the ipad and the very fast responsiveness of things like the apple pencil, which shows you that responsive hardware and software is definitely possible.

Re: Performance Matters

#123

Post by djmips »

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…

John Carmack doesn't work hard to eliminate 3ms of frame latency simply because of personal passion. In VR applications, latency kills and will make people sick. Those hard fought ms are needed. You only have 11 ms per frame at 90 Hz.

As someone who works in the performance arena myself I feel like a lot of the work I do is undoing the mistakes that the attitude that it's OK to not care about performance so I'll just do it the 'easy' way. It's pretty much a form of technical debt that is somehow culturally acceptable. For years we've had Moore's law covering everyone's asses but perhaps there will be a reckoning yet.

Re: Performance Matters

#124

Post by l0b0 »

This sounds like a clear case of consultant software. The people building it won't be dogfooding the result - at most they'll be clicking around the UI on their powerful desktop machine and patting themselves on the back because it responds in less than half a second. The requirements will be vague, because getting performance requirements anywhere beyond stupidly vague "performant on modern hardware" or some shit requires real expertise in UI design and will cost real money to build, and UI designers won't be involved in the details until the contract is signed.

"Premature optimization" in reality is a vacuous phrase, because premature anything is bad - it's right there in the word! (Insert joke here.) The problem is that most developers (myself included in many cases) are just not qualified to say when it is premature to optimize, because the requirements do not state anything meaningful about performance.

If you think this is overly pessimistic, I would encourage running pretty much any Android app or opening any major website on a 2018 or older smartphone. It's pretty obvious developers don't know how to build software for the probably 50% or more of customers who don't buy a new top-of-the-line phone every year.

As for performance guidelines, have a look at Jakob Nielsen's amazing evidence-backed UX guidelines such as Response Times: The 3 Important Limits[0]. The ones which should stick are that 0.1s feels instantaneous (probably not when using a scroll bar, but that's another matter) and 1s is the limit for not interrupting the user's flow of thought. In other words, if anything your program does takes more than 0.1s to respond to user input on the target hardware that should at least be acknowledged and prioritized (maybe at the end of the backlog, but at least then it's a known issue).

[0] https://www.nngroup.com/articles/response-times-3-important-...

Re: Performance Matters

#125

Post by wawawiwa »

Why does this post have so many points? How is that article useful to most readers? I sometimes don't understand HN.

Performance matters... the article talks about a case that most of us aren't confronted with.

Beside, it concludes that in spite of paper being slower, it's still prefered, so how does that prove that "performance matters"?!

Should an article be upvoted just because an article is about life and death and has a catchy (pretentiously) laconic title?

Re: Performance Matters

#126

Post by defined »

hacker_9 wrote: post #29
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 is a non realistic reply, as if optimisation is something that can be tacked on after. The truth is you have to walk the fine line between performance and maintenance. It's good to plan ahead and be able to optimise on the bigger picture early, so the design can go through several iterations and code reviews and therefore be trustworthy at the end. Your example of caching is almost basic programming, maintainabl…

eke

Re: Performance Matters

#127

Post by defined »

jasonlotito wrote: post #89
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. T…

Thank you for writing this. So many people don’t get it. You cannot tack performance on after the fact like some aftermarket pony car part if the performant architecture is not there to support it.

Re: Performance Matters

#128

Post by defined »

agentultra wrote: post #6

I believe performance does matter and should factor into the design of a system. There is an ISO guidelines on software system requirements and specifications that has a section for performance requirements. It does matter even for banal, non-critical or non-life-threatening software systems. Another often-overlooked requirement: environment. Does the human using your software system have to pay attention to more imp…

I’m with you, but good luck getting some scrum shop to include enough detail to achieve this.

Re: Performance Matters

#129

Post by defined »

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 is too narrow a focus. Performance starts at the architecture level and can’t be bolted on after the fact.

Re: Performance Matters

#130

Post by defined »

cookiecaper wrote: post #96
rossdavidh wrote: post #74

Earlier quoted context omitted.

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

Maybe the missing key component is the role of architecture in providing a platform for performance ;)
Post reply on HN