Which one do you use? The answer, of course, is "it depends." If X is some cronjob that runs once a month, it doesn't really matter if it takes five seconds of background process time, so there's no point in wasting time writing the hard version. On the other hand, if X is some calculation that must be executed thousands of times per day by users who need immediate feedback, then the one-second version is clearly preferred. And finally, how likely is it that X will change? Chances are the inefficient algorithm is more general and the efficient one more fragile.

Optimization is important -- but it's equally important to know when to optimize and to know what to optimize for.

Mod_Perl is an optimisation

There's a lot more to mod_perl than simply the response phase. For everything else, mod_perl is not an optimization, but something that is adding serious functionality. For example, I rewrote mod_usertrack in Perl so that it actually worked on my installation. I also have log handler that writes directly to DBI. Neither of those are an "optimization": they are essential functionality.

Whatever, all in all I agree with you: Optimisation isn't a dirty word..

I won't say anything about premature optimization because you've been lectured enough about it :), but there's an interesting distinction in regards to mod_perl. Specifically, there's a huge difference between the speed of a given program (which you might not care about) and the speed of all programs (which you certainly would care about). With mod_perl, we can gain the latter while using a certain environment and that is certainly not something folks are inclined to complain about.

I won't say anything about premature optimization because you've been lectured enough about it :)

Since you brought it up :), and as proxy to everyone else that did so, I'll respond to the lecturing here.

There is a strange, but verifiable fact about the process of optimisation: The earlier^* you do it, the easier, more effective and less troublesome it becomes.

^*Here the word "earlier" is deliberately chosen to contrast with the word "premature". You can look up the various definitions for premature, but let's derive our own:

• 'pre' - preceding, before, early.
• 'mature' - considered and perfected, ripe, complete, full-grown.

  Now here's the thing. You develop your latest greatest XYZ application. You follow good, sound, SE/CS design and development principles. You eshew optimisations in favour of simple, clear maintainability. You test, document and verify. Your application is mature--it just runs too slowly.

  So now it is time to benchmark and optimise. But to do so, except for the most simple of applications, you have to dissect and re-write large parts of your application, re-write large parts of your test suite, and re-test and re-verify the whole darn thing.

  Retro-fitting optimisations, whether algorithmic or implementation, to an existing complex application is always considerably harder than writing them efficiently as you go.

  The problem with the interpretation of the "premature optimisation" axiom is that all too often people fail to miss that coding is hierarchal.

  With the exception of the simplest of applications, we code in layers. And the lower down in the hierarchy that a layer comes, the more effect it's efficiency (or otherwise) will have upon the overall efficiency of our application. And, attempting to improve the efficiency of those lower layers, once we already have upper layer dependencies upon them, the harder it is to do without breaking those upper layers.

  It has to be seen that optimising library code, inner classes and similar lower layers, at the time of their creation--is not premature! It maybe before the maturity of the (first) application that uses them, but optimising a library or class prior to it inclusion in an application is an integral part of it's maturisation.

  If we are serious about code reuse, we must realise that when we code classes and modules that we intend to be reusable, that it is incumbent upon us to consider making them as efficient as we can (subject to the bounds of correctness, usability and reasonable maintenance), regardless of whether that efficiency is required for the first application for which they are designed.

  Only in this way can we ensure that those classes, modules and libraries will be efficient enough for the next application that would like to use them. And the one after that.

  Leaving (reasonable, achievable) optimisations as an after-thought, as a last minute "we'll do it if we need to" step in the overall development plan, can lead to huge costs and overruns.

  Imagine trying to retroactively gain the kind of benefits we all derive from the internal optimisation that Perl has, on a case by case basis at the application level?

  Alternatively, if Perl was able to save the byte code representation of it's code, and relocatably reload these, (very effective, mature and clever) hacks like mod_perl would not be necessary⁺.

  ⁺For their performance benefits. In deference to merlyn's advice about mod-perls's other features.

  ---

  Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

  Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

  "Science is about questioning the status quo. Questioning authority".

  In the absence of evidence, opinion is indistinguishable from prejudice.

It has to be seen that optimising library code, inner classes and similar lower layers, at the time of their creation--is not premature! It maybe before the maturity of the (first) application that uses them, but optimising a library or class prior to it inclusion in an application is an integral part of it's maturisation.

This is true only to the extent that the interface to the library is influenced by it's implementation, is it not? Isn't the point of libraries and library calls to abstract away all the underlying complexity, and to leave the details open to optimizations?

And yes, I'm playing devil's advocate for a moment, because I've seen the exact scenarios you describe, where "we'll speed it up if we have to" inevitably led to "we don't have the time/money to re-write the central data structures/premises underlying the application three weeks before our due date". I'm interested in seeing why those assumptions failed (and they did), because in theory, it all should have worked out...

Now here's the thing. You develop your latest greatest XYZ application. You follow good, sound, SE/CS design and development principles. You eshew optimisations in favour of simple, clear maintainability. You test, document and verify. Your application is mature--it just runs too slowly.

So now it is time to benchmark and optimise. But to do so, except for the most simple of applications, you have to dissect and re-write large parts of your application, re-write large parts of your test suite, and re-test and re-verify the whole darn thing.

The problem in this instance is not lack of optimisation. That's just a symptom. If I have to gut my application and start again because it turns out to be too slow then my development process is completely broken.

Performance requirements are part of the spec. I should be developing in small end-to-end increments so that I can continually look at whether my application is meeting performance requirements and optimise appropriately.

Do people really think optimization is a dirty word? (Or did you just mean the British spelling of it? ;-)

Usually, I see people railing against premature optimization -- or about optimization not backed with benchmarking. Much is done in the name of optimization because it sounds so reasonable -- that doesn't make optimization itself unreasonable or undesireable -- but it rightfully brings scrutiny on justifications based solely on optimization. It's important to differentiate between the two.

(Substitute "liberty" or "equality" or "security" or the moral good of your choice for parallel arguments outside of programming.)

see also money is the root of all evil vs. the love of money is the root of all evil.

--MidLifeXis

What people caution against is a knee-jerk type of optimization where a coder dives into an algorithm and emerges with a few more micro-seconds and a blob of horribly unmaintainable code.

Rather, code it cleanly and correctly from the start. If it's too slow (quantify and measure that), consider faster hardware first, it's usually cheaper than coder time over the long run. If your hardware is already good, identify the source of the majority of the slowness. Once you have metrics that point at your target, optimize that code with appropriate commenting to explain what you are doing and why. Re-test and verify you've made it fast enough.

So optimization isn't bad, it's just not the first thing you should jump on when something seems slow.

If it's too slow (quantify and measure that), consider faster hardware first, it's usually cheaper than coder time over the long run.

That I disagree with on multiple levels. Sure, if you as a developer only write one program, which noone wants so it's running just on your box, you are right. It's cheaper to upgrade your hardware than spend time optimizing your program.

But if your program actually gets run on several thousand of different boxes, it become a different matter. Upgrading 2,000 boxes for $500 each means spending a million dollars. That's a few programmer years. And if you produce a program once a month, and each time you're investing in faster hardware, you'll run into limits (the bottom of your wallet, or the state of the industry) pretty fast as well.

Perl --((8:>*

But if your program actually gets run on several thousand of different boxes, it become a different matter

Sure, but 90% of software development is done as some for of in-house customization work. Less than 10% is coding software as an industry commodity. Very, very, very few apps will ever make it onto hundreds, let alone thousands, of different boxes. Of those, the hardware upgrade benefits will in some cases be justified. Your point attacks a straw man; the common case is so far removed from your argument as to be entirely inapplicable.

And if you produce a program once a month, and each time you're investing in faster hardware

Almost no one produces a program "once a month", nor invests in faster hardware "once a month". It takes at least three months just for the average department to decide upon what it wants, let alone document those wishes clearly enough for them to be written into a program of noticable complexity. Again, you're vigourously assaulting a non-issue.

Upgrading 2,000 boxes for $500 each means spending a million dollars. That's a few programmer years

Well, at my company, we wasted several programmers years trying to do an in-house optimization as part of a code cleanup. It didn't work; the designer of the new system was incompetant. The new code is as ugly as the old; and the "optimizations" slowed things down so badly that we bought new hardware to solve the problem. How did we eventually triple the throughput of our program? We ran four copies in parallel on a quad-CPU machine. ;-)

In many places, putting just two contract programmers on a project for three weeks costs the company about $10,000. Buying $10,000 worth of hardware is probably going to give you a faster running program, sooner, for the same cost to the company. If the program gets scrapped by upper management, the company can still make use of the hardware; it's a generally valuable asset. Not so for the optimized code; it's a strictly limited use asset. Unlike the optimization effort, the hardware optimization is very unlikely to introduce bugs into the software. Unless you're buying a lot of hardware, (and most companies aren't) it's just no contest.

So, unless you work for Microsoft, or some other software vendor, you don't need to optimize code as badly as you need it to be bug free. Fast hardware is cheap. Fast software is expensive.

That I disagree with on multiple levels.

Actually, I think your argument agrees with what I said. I said

consider hardware first

In the example you provided, you considered hardware and concluded that it wasn't practical to purchase new hardware to solve the problem. My suggestion was to at least evaluate hardware improvements as an option before you throw coder time at the problem. Coder time can sometimes seem "free" since they get paid every two weeks anyway, but there is still a cost to someone doing work.

So I agree with your assessment for cases where a hardware upgrade is prohibitively expensive.

I mostly agree with your post, and I also agree with most of the responses I've seen. I'm quite enjoying this discussion; thanks for that. There's one thing at the end of your post that I haven't seen addressed, though:

if there are two ways to do something, and one costs less than the other and they are otherwise equal, use the one that uses less

This is pretty clearly true, but I have to wonder how often two things are "otherwise equal." In my experience, there's almost always a tradeoff. Other replies have mentioned specific tradeoffs and examples, but I think it's also good to keep the general idea in mind, and keep an eye open to the balance involved in these kind of decisions.

Ah, yes, thanks revdiablo. I too was getting sucked into the CPU cycle part of the optimization arguments. We all need to remember that there are several dimensions to optimization:
• CPU cycles
• space (memory, hard drive) usage
• maintenance & readability
• generalization and reusability
• flexability

I'm sure I'm missing others, and flexability could arguably be part of the reusability 'dimension'.

-Scott

OK, now I'm embarrassed. I was focusing on CPU performance optimization, too, despite my recent ranting about this topic. Oops.

Cheers,
Ovid

New address of my CGI Course.

I almost always favor in order:

1. maintenance and readability
2. flexibility, generalization and reuse (if you have to do something twice, you'll need to do it 1000 times).
3. space
4. CPU cycles

99% of the time the last two don't matter. Item 1 matters 99% of the time. Too much focus on generalization will cause you to either write a Turing complete language or never finish your project. Generally, some generality is good (heh).

Readable, well organized code is much easier to tighten up speed or space than overly tweaked "great idea" and "nifty hack" laden code.


TGI says moo