Looking for something in the abyss of my GTalk history I found short fragment of conversation with my friend:
- But that’s the much less frequent scenario.
- Yep, but perfectly optimized.
That reminded me all of different optimization tasks which I was doing, supporting or heard about. Few success stories. Several with limited effects. A couple of spectacular failures. And when I analyze them I think there are two rules which differentiate those which had a chance from those which were doomed from the very beginning.
1. Check first. Check before you start changing any code do some test. Even when you’re almost sure where the problem is. Make some load tests. Add counters if needed. Hack through logs. And after several weeks come with confirmation of your initial idea. Or something completely different. You never know unless you check. Another benefit is that after all that hard work you’ll feel very well for a while: “Ha! Got you! You can’t run, you can’t hide. Now, you’re mine. It’s payback time. I’m going to optimize you!”
2. Start from the most frequent operations, not the longest ones. It really doesn’t matter that it lasts a quarter to prepare this incredibly complex report because it’s done once per year, and you can stand an accountant yelling with frustration as often. Better take care about this little function which is called twenty times per every darn second. If you can earn 10 milliseconds on its execution you’ll earn 1752 hours per year. 2 and half months of your users’ time. I guess it’s a bit better than 15 minutes on execution of the report. And yelling accountants are strongly overrated anyway.
I’d try those two another time when you hear “Hey, I’ve read that when we use application server in our architecture we’ll scale up much easier. Let’s do it!” And believe me, you can hear something like that faster than you think.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
