if Perl isn't very bitpicky, it is probably not the language for me. I want to code as efficient as I can, otherwise, what's the use? It will be bad code since it could have been written better.

Evaluating the quality of code is something like a beauty contest. Putting everything on how fast it runs is like deciding the winner based on how fast she answers the interview question. There's a degree to which speed matters, but more important is whether the answer satisfactorily addresses the question. And what about the swimsuit competition? Does your code provide complete coverage with a minimum of excess? Or the eveningwear: is it so elegant and appealing that you'd want to show it off to your friends?

And don't underestimate congeniality. Programs that don't get along with other programs are not winners.

Writing efficent code is important. But it's far more important to write code efficently. Which is a more important optimization problem:

1. Write a program to do such-and-such. You have a month, after which we will time everybody's program, and the fastest program wins.
2. Write a program to do such-and-such. The first person to finish a program that can do it wins.

Perl isn't a good language for writing fast code in. It is a good language for writing code in fast. That isn't to say you ignore computer-time-efficency issues... but you worry about the ones that cause 10% slowdown, and not 0.001% slowdown. If you need more speed, then you start worrying about the readability-vs-execution-speed tradeoffs, or rewrite the bits that need more speed in C.

Of course, nothing in this node is to be taken too literally. I'm exagerating for effect. But think long and hard about it.

Perl isn't a good language for writing fast code in.

If I agreed with this I'd be disappointed - the perl porters put a lot of effort into improving the speed of perl, and trying to avoid speed loss.

It is true that perl wouldn't be a good choice for an interrupt handler (say), where you need to be able to impose very tight bounds on average and maximum latency.

However I have written lots of code that needed to be fast simply because it was doing an awful lot of work - the sort of recursive calculations that require billions of iterations - and I've found perl fine for such work. And for those cases, shaving a few microseconds can make a noticeable difference.

Similarly, when some code will create many millions of in-memory records, the few bytes-per-record saving that means you don't start swapping can also make a big difference.

I think the assembler background does give a helpful tint to the mindset, in that you get into the habit of applying the various micro-optimisations automatically, and the benefits do mount up.

The important thing though is to keep a balance, and not let the optimisations affect readability (hence maintainability) too much; and to remember that finding a slightly better algorithm will likely put all the micro-optimisations into the pale.

Hugo

While Perl may be able to execute code fast, that isn't the focus of the language. The focus of Perl, as documented by many more Perlish than me, is to improve programmer efficiency. Now, it's nice to have efficient programmers while still having somewhat efficient programs, and I love it when that happens. I love being able to write programs extremely quickly that just happen to run quick enough so that I don't have to rewrite them.

But, the point theorbtwo is making is that, for the first writing of a program, you shouldn't worry about CPU speed, RAM, disk, or any other plebian item. The items that need to be concerned with in the first pass, in order, are:

1. Does the program do what it needs to do?
2. Does the program have any horrible crash-me type bugs?
3. Did I finish the program in the time allotted to me by those paying me?
4. Does the program have any medium-sized bugs that will occasionally trip users up?
5. Is the program fast enough for the average usage?
6. Does the program have any bugs at all?
7. Can I improve the program's internal structure to make future changes easier?
8. Can I improve the program's internal structure so that someone else can make changes without messing up my stuff?

Now, a requirement for item #1 may be "Execute in such-and-such time", in which case execution speed is a priority above programmer time. And, if that's the case, then Perl may not be the appropriate language for such an endeavor. If it is not, then Perl may be appropriate.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.