A golden rule of performance improvement
The Rule: Performance optimizations are not worth making for anything less than 10% improvement in speed.
Corollary: Performance optimizations must be measured before and after, and changes reverted if they do not cause significant performance improvement.
Converse: If you are pushing back on implementing a feature “because it will make the app unbearably slow”, particularly if that feature is deemed a security requirement, you had better be able to demonstrate that loss in performance, and it had better be significant.
I come about this insight through years of work as a developer, in which I’ve seen far too many mistakes introduced through people either being “clever” or taking shortcuts – and the chief reason given for both of these behaviours is that the developer was “trying to make the program faster” (or leaner, or smaller).
I have also seen developers disable security features, or insist that they shouldn’t implement security measures (SSL is a common example) because they “will make the application slower”.
I have yet to see a project complete a proper implementation of SSL for security that significantly slowed the application. In many cases, the performance testing that was done to ensure that SSL had no significant effect demonstrated that the bottleneck was already somewhere else.