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
In reply to Re^3: Using aliases in for loops or not?
by hv
in thread Using aliases in for loops or not?
by jkva
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |