It's a common sense in the industry that performance tuning should be done after feature complete. But very likely there is only a small time frame between feature complete and code freeze, and during this short time period we need to do so many more important things. There is another common sense after product release, if it ain't broken, don't fix it. Performance issues, if any, are far from being broken.
Sounds weird, but such is life. Thanks to modern programming languages, revolutionary methodologies, cutting edge hardware, we are in a time that you don't need to know how many registers are there in a CPU to development software. And more importantly, nobody actually knows what performance can be achieved for a certain system on a specific platform. I have some real life performance tuning examples and the amazing results here.
From 5 Minutes to 90 Seconds
When I worked in a product called Public Content Management 8 years back, there was a home-made caching system in this product. It worked beautifully after system is started but it took 5 minutes for the system to start. It became so frustrating that my manager gave me a week to figure it out if we could do something. By the end of the 4th day, the product was able to start in 1.5 minutes. After this, I began to pay more attention on what can be done to:
- finish a time consuming task in (much) less time; and
- leave more CPU cycles to customers.
And from that time, I put "Performance Tuning" as a speciality in my profile.
From 7 Seconds to 70 Milliseconds
Last year I participated in a system called Marin Safety. From my development environment, the loading of Waterway Management page took 7 seconds. I knew that this was mainly because I was using a remote database instance, which was not the case in a production environment. An amplified performance issue, ignore it or not? Several hours later, I shortened the loading time to 70 ms.
From 13 Seconds to 182 Milliseconds
Last week, I needed to parse some returning strings of WMS calls from a GeoServer. I could select format from text/html and text/plain. I should have one more choice, text/xml, according to the protocol. XML format was obviously the choice because it's self-explained and way easy to get parsed, but GeoServer doesn't even support it. HTML format is reasonably my next choice, it's at lease easier to parse than plain text. But for a sample request, it took GeoServer 13 seconds to return an HTML format result while only 182 ms to return a plain text result. I'm sure you know my answer at this point of time. Do the hard work myself and save user 10+ seconds per call.
From the above examples I just want to give you an idea about performance tuning. It can be done and should be done any time, especially when the environment is not ideal. The fact is, ideal environment (usually production environment) can only cover the performance issues, it won't solve them. It's too late to start performance tuning when you start thinking upgrade your sever or losing your impatient customers.
