When we talk about "improving performance" we're referring to things like greater throughput, more concurrent users served, improved responsiveness. Putting aside blue pills and nasal delivery systems, scaling application development is after much the same thing. When it comes to web applications, delivering your message as fast as you can leads to greater user satisfaction.
Note, "feel" is that un-quantifiable quotient of joy (or un-joy) users experience when interacting with your code.
For dynamic pages such as ColdFusion, ASP.NET, and PHP, simple queuing theory suggests a tipping point at around about 250ms per page. If you can get your page clear of the server in under 250ms you really start to make a difference. Get it down to 50ms and the whole "exponential" thing starts to really kick in.
Efforts to improve performance often centre around bigger "iron" — throw enough hardware at the problem and magic happens. And funnily enough you’ll often find the cost of servers these days is cheaper than the cost of good development. Alternatively, folks obsess about the speed of arrays versus string manipulation and other such miscellany. But trying to wring every drop of speed out of code execution can lead to all kinds of unpleasant compromises.
Take a load off! That’s what I say.
Look at the problem side on. Maybe you don't need to go faster, but to go in another direction entirely:
- Do as little work as possible for user driven requests
- Do all the work before or after the request
And with that cryptic conclusion, I'll leave it there for tonight.