There's been a lot of recent discussion regarding premature optimization and I though I should post a node clarifying why premature optimization is a bad thing. Much of this node is from a response I made to the Perl Beginner's mailing list earlier today. Go there, sign up for the mailing lists and help people develop warm, cuddly feelings about Perl.
There's a saying that there's only one thing you need to know about project management: "fast, good, or cheap, pick two". These three variables refer to development time (not speed!), quality, and cost. They assume a fourth variable: scope. In any given development environment, you can usually control about three of these variables. Examining the impact on the fourth allows you to determine what's an appropriate response to what you are doing. Remember those variables:
- Scope
- Cost
- Quality
- Development Speed
Now, obviously no one wants to sacrifice quality (though, in practice, due to poor planning, that's one of the first things to get sacrificed), so let's mentally cross that off the list. If your clients are really picky, scope is also difficult to sacrifice. So, the cost of the project and the development speed (cheap and fast) are often what gets left over. Cost is often affected by things other than programmer hours (licenses, travel, hardware, etc), but it's closely tied to it. As a result, the faster the development speed, the lower the cost tends to be. I guarantee that for any given application, competant Perl programmers will kick the snuff out of competant C programmers in terms of development speed (this was originally a response to someone asking about the speed of C vs. Perl).
Note that nowhere in there did I say anything about "how fast the program runs". If it runs fast enough for your clients, it's fast enough. Period. If I tell a client, "oh, I can do this project in half the cost in a third of the time, but your program will run a bit slower", many, if not most clients will opt to save the money.
Of course, I wouldn't write device drivers in Perl and currently, I'm working with Inline::C to learn how to optimize certain portions of my programs (Inline::C is embedding C in Perl), but dollar for dollar, our clients love Perl and would rather fight than switch.
This is not to say that the speed of an application is irrelevant. I've used desktop programs written in Java that were very powerful, fit my needs perfectly, and couldn't outrun a quadraplegic snail (whatever that means). As a result, I don't use those applications. That still doesn't mean that you optimize for speed up front. You optimize for clarity. Clear understand code is easier to optimize for speed than is code that has been obfuscated by premature optimizations.
So how do you optimize? You start doing that near the end of a project when you have a clearer idea of your overall project and the various pieces interact. Plus, as best as possible, you optimize with real-world conditions. If you're testing against a 100 line dataset, but your actual datasets are millions of lines, you're really not testing. Many Web developers make big, beautiful apps that are lightning fast -- but only when run locally.
Once you have near real-world conditions for your nearly complete code, then you can start using Devel::Dprof to find your worst offenders and Devel::SmallProf to profie things line-by-line.
A useful bit of information about this is Re (tilly) 1: Why Use Perl?.
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.