optimizaqtion, in a mathematical decision-making context, refers to finding the appropriate balance between resources expended and return. when the hardware you are using would be valued at $50-75, it's hard to justify spending $150 of my time squeezing cycles until i've reached the point at which the new stuff i want to add is contrained by what is already running (or the other way around, whichever way you want to look at it.)

look at it this way. i work in the labs of a state health department. if i deliver three solutions that occupy 6 hours a day on a machine that would be surplussed if i weren't using it, is that less optimal than delivering two applications that run in two hours? which solution do you think the taxpayers would prefer?

Liberating words. A theme I've read dragonchild on, more than once. Code needs lots of different kinds of resources to run. CPU, memory and all that stuff, sure, but also Write Time and Fix Time. Perl seems to shine when those last two are the ones you want to minimise. And given that everything else is getting cheaper and cheaper, that's a good strategy (as well as being one instinctively favoured by the geeks who do the Write 'n' Fix). For me, self-"employed" (quotes meant to dispel any illusion I might be getting paid) writing an application for a web site well past its launch date, this translates into "if the site goes live a month earlier, it'll make enough money in that extra month to pay for the RAM and processor speed you would have saved by farting around getting the code to go quicker."

Nevertheless, I always find myself worrying about little improvements that take a long time to get done. Perhaps this confession will help me to cut to the chase with renewed vigour.

§ George Sherston