We're getting to the extremes of programmer time vs execution time at work. This is interesting, because I've always believed in the mantra that we use perl because programmer time is more expensive than execution time - you can always buy more hardware for less cost than the programmer.
But if we have to put out N new towers to be able to scan all the email we receive (a tower is a rack filled with email processing hardware), at a cost of about $250,000 per tower, that's a lot of extra cost to fill our capacity requirements. At these extremes it is actually more efficient to throw out slower programming languages and hack in something with better performance, even if it takes you longer, or you need to add many more programmers to the project.
Maybe next year I'll be going to C programmers conferences (are there any?)...
actually more efficient to throw out slower programming languages
You're finding that there's no distinct bottleneck in what you're processing? Hence you're not in a position to merely change the slow routines from (say) a perl to a C implementation? (because there is no subset of routines which are "slow")
