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

101–110 of 141 posts

Re: Performance Matters

#101

Post by filoleg »

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

>a stylus will just get lost within the first day

Extremely relatable. Someone needs to come up with a stylus that is permanently attached to a laptop using a wire or some other sort of contraption, similar to writing pads with permanently attached pens. The slot (hole) for the stylus should still stay, so that it can be packed up/stored neatly.

The main reason it was not done yet, my guess, is because of the dangling cable from the tablet when the stylus is stored in the slot, but it could be retractable for storage or something like that.

Re: Performance Matters

#102

Post by desc »

hinkley wrote: post #79

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…

Indeed.

"If I have to pay nearly as much or more attention to the use of this software than it saves me, it is by definition worthless."

Intellisense in VS/Resharper went through a nice period a few years back where it was smart enough to match what was meant, fast enough that it didn't (usually) drop keypresses, and (crucially) stupid enough that typing the same thing twice would get the same results. Sadly, all of the above have been lost in the hail of features...

Context sensitivity is not always a good thing in a tool. Muscle memory wins.

Re: Performance Matters

#103

Post by seanmcdirmid »

filoleg wrote: post #101
JshWright wrote: post #85

Earlier quoted context omitted.

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

>a stylus will just get lost within the first day Extremely relatable. Someone needs to come up with a stylus that is permanently attached to a laptop using a wire or some other sort of contraption, similar to writing pads with permanently attached pens. The slot (hole) for the stylus should still stay, so that it can be packed up/stored neatly. The main reason it was not done yet, my guess, is because of the danglin…

Or just use a resistive digitizer above the screen and make anything with a tip a stylus, so they can be disposable and replaceable like pens.

Re: Performance Matters

#104

Post by Faark »

novok wrote: post #78
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…

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 got any sources. The ones I've found were not that great but don't paint such a good picture. [0] is an article claiming touch sensors scan only once per frame, aka 16ms at the time. [1] claims ~85ms to response on an iPhone 4, ~55ms on iPhone 5. How were you able to easily beat those by such a margin?

[0] https://www.anandtech.com/show/9605/the-ios-9-review/9#Input...

[1] https://www.cnet.com/news/iphone-5-touchscreen-2x-faster-tha...

Re: Performance Matters

#106

Post by joshstrange »

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…

My boyfriend is a nurse and said a very similar thing. He said he very rarely looks at a PCR as everything important is conveyed verbally when the handoff from EMT->Hospital.

Re: Performance Matters

#107

Post by bbojan »

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…

Check out https://danluu.com/input-lag/ , where the author measured latency between a keypress and the display of a character in a terminal for systems built 1977-2017.

For example, Lenovo Carbon X1 4th gen running Windows has about 5x the latency of an Apple 2e.

Re: Performance Matters

#108

Post by dahart »

mntmoss wrote: post #99
dahart wrote: post #66

Earlier quoted context omitted.

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

Ah, I've been meaning to read Racing the Beam for years!

That's all true, and thanks for an insightful comment!

I would just add though that it's easy to frame things in a way that makes it seem harder than it really is to maintain responsiveness. For example, while yes caching makes guaranteeing exactly repeatable timing a problem, that's an issue at the nanosecond/microsecond level, and not really a problem at the millisecond (human perception) level at all. Today's hardware doesn't have issues maintaining 60hz unless the software isn't even trying.

Another counter-example would be that while yes, browsers and desktop UIs are doing compositing and don't have direct access to the pixel buffer, the compositing is actually done on the GPU via low-latency commands. Direct access to the pixel buffer would actually be much slower than what we have right now. The browser has no trouble responding and rendering at 60hz unless you do things that cause more than the ~16ms of compute you have time for. Triggering page reflows will do that, but compositing an animated WebGL canvas over something else on the page is plenty fast.

Re: Performance Matters

#109

Post by dahart »

bbojan wrote: post #107
dahart wrote: post #66

Earlier quoted context omitted.

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…

Check out https://danluu.com/input-lag/ , where the author measured latency between a keypress and the display of a character in a terminal for systems built 1977-2017. For example, Lenovo Carbon X1 4th gen running Windows has about 5x the latency of an Apple 2e.

This is a great chart, and I've seen it before here on HN.

Just in case you were thinking this is perhaps a counter-example to what I said, I think it's the other way around, it very much supports my claim. The processors have (obviously) gotten faster, and yet for some applications latency has seemingly gone down. Why? Software and requirements are the reason, not hardware.

Terminals also are not an example of the "best systems" in terms of latency. You'd be much closer if you looked at video game latency, or tracked industrial applications that have low latency requirements from the start. The whole reason terminals have gotten slow is that they aren't trying to go fast.

Quite a few of today's most modern terminals have recently added performance as a feature, started rendering with the GPU, and quite predictably, they are restoring super fast response times to our terminals. iTerm2 would be an example of this.

Re: Performance Matters

#110

Post by Diederich »

penagwin wrote: post #37
phkahler wrote: post #30

Earlier quoted context omitted.

>> The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.

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…

In 1995-1997, I wrote and maintained an application that was used, during every surgery, in critical ways in every operating room in a large, regional hospital.

This app ran on a regular computer running normal Microsoft Windows 95. It wasn't terribly complicated, but it also wasn't simple. It accessed a database over the wired network for most everything it cared about doing.

It took some thought and care, but it wasn't impossibly difficult to ensure that the app was always highly responsive.

I think it comes down to priorities. I worked closely with the doctors who were actually using this app on a day to day basis, and working with an app that didn't slow them down was quite important for them.

Post reply on HN