That's a red herring. Machine time is utterly unimportant. But what is important is the end user.

You've just called something a red herring that wasn't and then offered something that was. Of course, context matters and in another case I might take your stance but we are discussing this case. It's unlikely that the micro-optimization you offered would ever be noticeable by an end user. And, as your optimization didn't change the time complexity of the algorithm, even if a user came along with orders of magnitude more data than the average, the change would still be just as insignificant.

Would you accept it that the movie you're watching on your PC freezes because developer time costs more than machine time?

Firstly, if I was writing a multimedia application, I probably wouldn't be doing it in Perl, and if I was doing it in Perl, you can be sure I'd be using XS for the important bits. Secondly, if we were talking about an optimization that meant the difference between a machine freezing or not, we wouldn't be having this discussion.

In general, it's very hard to say anything about developer time vs. running time. Many programs aren't designed to be run once, they will be run thousands, or millions of times.

Though it may be hard to be exact in what you say about developer vs. running times, it isn't hard to make useful generalizations and get a handle on the big picture. If this program actually were run millions of times, your micro-optimization might succeed in saving hours of run time. But, those hours would still be amortized over all those runs and all those users and would still amount to an imperceptible benefit.

I've a hard time imagining a coder that would take hours more time to do the same amount of things.

I said "minutes to hours" as a contrast to the "seconds to minutes" of machine time. A change like this is certainly unlikely to take even an hour, but if you can't imagine it taking a lot longer than it should, I'd have to guess that's inexperience talking. What I was getting at was that the machine time saved over all runs of this program is likely to be worth less than the developer time spent making this micro-optimization.

A good coder will always program with efficiency in mind - doing thinks like this (lifting code that will yield the same result out of a loop) should be automatic.

That's true. And yet, even experienced developers can make mistakes like these when fatigued or under pressure. But, that isn't the issue. The issue here, and the reason for my initial response was your claim that

"The problem I have with [the original poster's] solution isn't so much the "cleanness", as well its inefficiency."

Again, it all comes down to context. It's true that, when you get a question like this, there's only so much of the context that you know or can discern. So, start with what you do know... things like "this is being written in Perl" for instance. That's usually enough to tell you whether a given micro-optimization is going to be important. In this case, it almost certainly isn't and the "cleanness" of the code is definitely the more important issue.

-sauoq
"My two cents aren't worth a dime.";