Optimizing Perl

An anonymous reader writes "Perl is an incredibly flexible language, but its ease of use can lead to some sloppy and lazy programming habits. We're all guilty of them, but there are some quick steps you can take to improve the performance of your Perl applications. This article looks at the key areas of optimization, which solutions work and which don't, and how to continue to build and extend your applications with optimization and speed in mind."

Comments

Optimization Rules!

[FooAtWFU]

The first rule of program optimization: Don't do it.
The second rule or program optimization (FOR EXPERTS ONLY!): Don't do it yet.

-- fortune

Re:Optimization Rules!

[Smallpond]

+1 insightful.

Look at his first example, which is concatentating 1 million strings. His "bad" time is 5.2 seconds and the good time is 1.7. Who cares? Nobody uses perl to do high-performance computing. Imagine you are extracting 1M strings from a database and doing something with them. Would you care about a 3 second difference?

Its OK to write good code, but its better to make your code clear and not dependent on clever tricks.

Re:Optimization Rules!

[Pseudonym]

Performance matters. And just like security, it can't be an afterthought.

Performance always matters. A program which computes the monthly payrolls is useless if it takes three months to run. However...

1. Performance may not be an issue in your particular program. If it's good enough, it's good enough.
2. "Performance" may not mean what you think it means. For one application, throughput (i.e. the amount of work you can do right before overload) is the most important consideration. For others, scalability, latency, memory usage or cache utilisation might be more important. Moreover, "performance" may not mean what you thought it meant when you started design.
3. A few minutes with the back of an envelope before you start coding often beats hours spent with profilers afterwards.
4. Time spent optimising the wrong piece of code is time wasted.
5. If performance really, really matters, plan to write a copy to throw away.
6. (And this is the most important of all...) The best favour you can do to your code with respect to performance is to write clean, well-compartmentalised code with good internal APIs and lots of unit and system tests. When you find a performance problem (and you will), you should be able to swap out bad code and swap in good code and (almost) nothing else will break. The corollary of this is that with performance, you need to design it in, but not necessarily code it in.

perl optimization vs general optimization

[BinLadenMyHero]

Many optimizations listed in the article are not pertinent to Perl, but to any programming language, and as such are inapropriate to be there. Like the part about avoiding calling functions inside loops, short-circuit logic, sorting, etc..

But there are some good tips there, too: the part about string handling, references, and the AutoLoader.

Re:No offense

[Anonymous Coward]

No offense, but if you require language constructs to keep your code clean and disciplined, you're a sloppy and lazy programmer.

AKA "How to micro-optimize in perl"

[fizbin]

Look, this kind of "squeeze the last bit of performance" exercise can be nice fun for assembly, or possibly C, programmers, but when have you had something that was acceptable as a perl script, but only after extensive optimization?

Better yet, I would have liked pointers on how to test code snippets for performance (such as illustrating the use of Benchmark or Devel::SmallProf), and then possibly a few pointers like this. (and why was Memoize left out of an article like this?) This sounds like someone writing perl who'd rather be writing assembly code.

In optimizing my (and others') perl scripts, the best tools I've found are the profiler and an understanding of what the code is supposed to do. That, and changing the nature of deployment of the program - from a cgi script to mod_perl, for example. All these little techniques are chasing after grains of sand, when there's a big rock right in front of your face.

Re:some comments

[justanyone]

4. Tabs: Tab is a nasty character that is not visibly different from x number of spaces. Lots of people like tabs. That's fine. Lots of people don't. That's fine, too. But, when 2 people work on the same code, bad stuff happens. Spaces ALWAYS get mixed in. This is bad. The easiest method to elim this prob is No Tab Chars. This can get religious, but BADLY ALIGNED CODE LEADS TO CODING ERRORS! This is a frequent mistake and costs time (and therefore money and anger).

6. The "bullshit... personal taste" aspect of brace alignment is both true and misleading. Really, it doesn't matter which way you do it, as long as you're consistent. But, with multiple people working on the same code, consistency is difficult. I've always done it with left brace on the left margin so I could easily see what lined up where. If your rule is opposite, fine, but USE ONLY ONE and code looks much nicer.

13. UNLESS (pardon my french) = stronzino (a little piece of shit). It's in the language to assist removal of a single ! 'not'. This can really confuse people. I'm not the smartest guy, nor the dumbest, but sometimes I see it and just go, "huh?". I'm not used to it. Neither have been many other Perl coders I know when we've spoken about it.

14. I take it by "Bah" you don't like scripts to log their actions. I've fought this recently with a 'know-it-all' type who wanted to build something fancy to do logging "when I get around to it". Yuck. Keep it simple, log what's going on so you can trace it later. Simple text files with "just did this, value=12" can help tremendously in debugging production problems. Users never know what they did; error messages never can contain enough info about what happened before.

16. GOTOs are evil. I admit to some brainwashing by CS profs on this, but have dealt with enough spaghetti code to agree with it. Yes, there are times when it's good. But, in my last 100,000 lines of Perl, I haven't had to use it yet. So, it must not be vital. My goal is simplicity of code, not speed, since who cares about speed most of the time anyway, unless it's really bad, in which case there's probably somethign you're doing wrong otherwise.

18. $_ is valuable only until you need to know what's in it. Then, you need a real variable name. You also may need that var to stick around past the next function call. I say, use 'my $request = $_; ' or something to grab $_ and make it obvious.

21. Declaring vars near use is good ONLY in subs. If you have:

exit(main());
sub main
{
do_jack($GV_DEF_ONE);
}
my $GV_DEF_ONE = 12;
sub do_jack
{
....
}

you'll get an error during parsing due to GV_DEF_ONE not being declared yet.

Regardless, Global vars are hard enough to spot and should be rare, declare them all at the top of the module to make it bloody obvious you're using one.

22. I can sometimes agree to my ($a, $b) = split(',',@inlist); but not disparate vars all crammed together on one line, it's not readable, the vars are hidden, not aligned and initialized, etc.

29. Lines of hashes visually indicate end of file. I can always tell I have the last page of a printout when all my files end with 5 or so rows of hashes. Just convention and a good idea, not a hard-fast rule.

Re:Optimizing schmoptimizing

[Anonymous Coward]

If the resource use isn't a problem and it leads to better readability and maintainability -- then, good for them! That's the right call.

Re:Best PERL Optimization trick ever:

[Samhain138]

They said optimizing.
You are aware that Python sucks when it comes to speed?
You should look at the python-dev mailing list about how many times people mentioned that Python is slow, especially for regular expressions.
One time someone suggested openning a perl process from within Python.
So think twice before suggesting slow languages.

NOTE: I personally hate Python, so I might not be too objective, but Python being slow compared to Perl is objective!