How do you know if your code is fast enough?

One of the big pains I’ve seen while at PR and X is dealing with customers, managers, and critics who go off on performance.

• When you click here, it takes too long!
• When you start up, it takes forever!
• When this page loads, I can go get a cup of coffee and it’s still loading!

All are valid concerns, but it gets a little ridiculous when you hear someone say “it needs to be 0.2 seconds faster” or “we have to be at least as fast as before even though we’re doing 10 times more processing”.

Perception, a qualitiative measure, is more important than quantitative measurement.

Given that Internet connection speeds vary, that client computers can be a few years old, and that humans can be sedated or caffeinated, it’s even more important to move beyond simple clock-watching.

David Weiss discusses performance on his blog and mentions a classification scheme for timing perception:

• Instantaneous (0.1 to 0.2 seconds)
• Immediate (0.5 to 1.0 seconds)
• Continuous (2 to 5 seconds)
• Captive (7 to 10 seconds)

So instead of simply whining about how things have gotten slower by 0.1 seconds, determine where your feature (broken down into actions or features or events, but that’s another topic) falls. Now, are you within range?

The other difficulty is deciding which category the feature should be in. This is where user studies matter. Your boss is not the ultimate arbiter. You are not the ultimate arbiter. Make sure your typical set of users would be happy with your choice by faking time delays in a mockup.