Hacker News Reader

Comment by nemothekid | Hacker News Reader

>But regardless of what our computer is doing, if it takes less than 100ms to execute our program, we simply won't be able to tell the difference between executing 1 instruction or all 10 billion.

>All of the example programs except for "Python 3 (PyPy)" are basically within this threshold. No user will notice the difference.

This is a contentious point. 100ms is very noticeable for a human being. I'd say most humans probably hit the "simultaneous" range at 33ms (30fps). I know, personally, I can very much tell when there's an input latency of 100ms.

Regardless, for Drew's somewhat contrived benchmark, I can't imagine a situation where starting a program in 33ms or 100ms would matter, but if that program was running in a loop in a bash script? Then those milliseconds very much do matter. Spending 90ms more in a loop is an extra 9 seconds for every 100 items.

View on HN

This is covered in the article, and he even does a benchmark of 25k iterations, and then explains why go is slower, creates a more apples to apples comparison where go is only slightly slower, and then optimizes the syscalls to create a go program many times faster than the asm.

I would argue if you're doing performance sensitive work in that fashion, you're doing it wrong.

I'd also probably argue that if you're doing it that way, you're probably already not that concerned with performance to the degree where losing a few tens of seconds is a big deal.

I certainly wouldn't include any tight bash loops that execute external code in any service code, for example. Performance there shouldn't be impacting either the sync or async path.

Much like the article's point, it's a question for optimising for the right things.

I do agree that people can perceive values faster than 100ms.

Several years back I was interviewing for a sysadmin job at a futures trading company. Part way through the interview, one of the traders complained to the interviewer that the latency was increasing on the connection to the exchange, and sure enough it was up 20ms from normal (I forget the normal, but it was very low, on the order of only maybe 10-20ms) and monitoring was just about to page the interviewer.

In addition to 100ms being very noticable, the problem with such "it isn't noticeable" arguments is that n such implementations get layered and soon you have a pretty egregious situation.

As a lazy example, I happen to have Excel open on macOS -- whenever I try to format a cell the format screen takes just shy of 4 seconds to appear. How is that even remotely possible? Tens of billions of instructions per second...leaves me waiting whenever I set a single cell to display as a number.

Memory utilization has the same problem. Those many allocations are meaningless individually, but pretty soon we have an idle and unnecessary "Adobe Desktop Service" sitting in the background soaking up almost 2GB.

There's a difference between perception of display FPS and action-reaction cycle, like pressing button and seeing result. Check out this video: https://youtu.be/eLK-L10zRFA

The guy is a super-fast gun artist, honing his action-reaction loop every day for hours. But for first 120ms he just standing there while nerve signals are getting from eyes to brain and then to his arms and fingers.

Also, performance isn't only about the time it takes for something to run and whether that will impact the user, but is also about resource usage.

Those milliseconds the user won't notice are still processing that is wasted and could potentially be used for something else

> I can very much tell when there's an input latency of 100ms.

These examples aren't really about input latency though.

Reply on news.ycombinator.com