Comment by giantrobot

> No, this mindset is a death sentence for good software. All it takes is a few people at each level of the stack making the same excuse.

To pile on to this, it's not just five milliseconds here and there in your application but its position in the rest of the system. Your application's 5ms regression is tested on an unloaded machine (for example). That means you lost 5ms on an unloaded machine with all its considerable resources available.

That regression is very likely to be much larger in a loaded system where your process is contending for resources. On a loaded system your 5ms regression becomes a 20ms regression along with everyone else's 5ms regression. So now the user is sitting there wondering WTF is happening.

There's a pretty good chance your GUI application will be running on a mobile device of some sort. This means it's running on a device with power limitations. The CPU might be vastly underclocked to save power or you could be running on an efficiency core instead of a more powerful performance core. Now your 5ms performance regression is possibly 100ms. A couple such regressions that "don't matter" on the 3GHz test desktop become significant on the user's laptop with 15% battery remaining that's clocked the CPU down to 600MHz.

Performance regressions should always be a concern and testing should to encompass the pathological worst cases. Even if there's nothing you can do about performance regressions (that 5ms of work is exploit mitigations or something) they should at least be quantified and understood.