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: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.