Fast Software

Recently, the many relevances of fast software have been impressive.

We often discuss network performance. We can make things a little faster here and there. We see performance improvements accompanied by improvements in success metrics. I found this kind of chart very satisfying. But perhaps even more interesting is thinking about the impact of speed. It might be the difference between I love this software and go to yours and I exit .

Craig Mod completely abandons Google Maps in "Quick Software, Best Software":

Google Maps became so slow that I did something incredible: I reinstalled Apple Maps on my iPhone. In contrast, today's Apple maps are very fast and responsive. The data is still not as good as Google Maps, but this is a good illustration of how slowness prompted me to reinstall an app that I've almost given up. I will try Apple Maps more in the future.

And pointed out the key points:

But why is it not good to be slow? Fast software is not always good software, but slow software rarely achieves greatness. Fast software gives users the opportunity to "integrate" with their toolsets. That is to say, the process does not interrupt.

Sometimes it even involves life and death! Hillel Wayne said in Performance Is Important that first responders in ambulances don’t use the built-in digital “patient care report” (PCR) system, but instead choose paper and pen, simply because PCR is a bit slow:

The ambulance I followed had an electronic PCR. No one uses it. I've talked to EMT about this and they say people they know don't use it either. Lack of training? «No, we are all trained. » Serious error? No, it works fine. Is the paper good enough? No, electronic PCR is much better than paper PCR in almost every way. It has only one problem: it's too slow.

It's not even that slow. When you open the drop-down menu or click the button, there is about a quarter of a second delay. But that makes things so unpleasant that no one wants to touch it. The paper is slow, annoying and error-prone, but at least it isn't that .

"Input Delay" is a key concept here. If your JavaScript is running and, as they say, "occupies the main thread", then this is exactly what can happen on the network.

Monica Dinculescu created a typing delay experiment that simulates this input delay. The 200 millisecond "We're done" setting is absolutely true. I'll never use software that feels like that. Jay Peters on The Verge agrees that any higher delay will worsen exponentially.

The extra interesting thing is: random latency is worse than consistent large latency, which is probably more common on our own websites.

The above is the detailed content of Fast Software. For more information, please follow other related articles on the PHP Chinese website!