~Particle *accelerates*

One caveat though: When printing a list, each element is evaluated in LIST context whereas concatenated expressions are evaluated in SCALAR context....

% perl -le 'print "Today: ". localtime()'
Today: Tue Apr 30 01:35:48 2002

% perl -le 'print "Today: ", localtime()'
Today: 5435130310221191
[download]

-Blake

Beyond performance improvement, some of these transformations usually render your code "more correct" (for some suitable definition of correct). Your first point, for example, about unnecessarily quoting variables: in my experience, it's a left-over bad habit of shell programmers. It can lead to errors in strange circumstances, particularly if $foo is an object, and the stringify operator does something you didn't expect, or you didn't realize the stringified version is not the same as the object itself.

More than optimizations, I would categorize these as "Refactoring". Generally speaking, it means changing code without adding functionality, but improving it in some fashion, such as making it easier to maintain. Fowler has an entire book on the subject. Although it uses Java, some of the principles apply to other languages as well.

I recall brother chromatic was working on a refactoring editor for Perl, based on using the B back-end compilers to generate a uniform code tree, then applying these types of changes. He referred to it in his journal on use perl, but I don't know its current state (though I'm sure it'll be thoroughly tested when it's released ;-).

Use  $foo = $x || $y || $z;  This is much faster (and shorter to say) 
+than:

   if ($x) {
      $foo = $x;
   } elsif ($y) {
      $foo = $y; 
   } elsif ($z) {
      $foo = $z;
   }
[download]

--Jim

... Before submitting this post, though, I decided to actually benchmark some variations to see whether character classes were faster. To my surprise, it turns out that /i is about 50% faster in the test I used:

use strict;
use Benchmark qw(cmpthese);

my $foo = "abcdefghijklmnopqrstuvwxyz"x500;
my $re = "[Aa][Bb][Cc]";

cmpthese(1000000, {
  'i'       => sub { $foo =~ /abc/ig },
  'chars'   => sub { $foo =~ /[Aa][Bb][Cc]/og },
  'charvar' => sub { $foo =~ /$re/og },
});
[download]

Benchmark: timing 1000000 iterations of chars, charvar, i...
     chars:  2 wallclock secs ( 1.97 usr +  0.00 sys =  1.97 CPU) @ 50
+7614.21/s (n=1000000)
   charvar:  3 wallclock secs ( 2.04 usr + -0.01 sys =  2.03 CPU) @ 49
+2610.84/s (n=1000000)
         i:  1 wallclock secs ( 1.31 usr +  0.00 sys =  1.31 CPU) @ 76
+3358.78/s (n=1000000)
            Rate charvar   chars       i
charvar 492611/s      --     -3%    -35%
chars   507614/s      3%      --    -34%
i       763359/s     55%     50%      --
[download]

The problem with //i isn't (wasn't?) that it's slower on small strings. It's that it uses twice the memory as an equivalent character class. And when you start matching against huge strings that can really make a difference. Try your example against a 50MB string and I think you'll see what I mean. If not you can justly castigate me for being too lazy to test my own assertions.

Eagerly awaiting the second edition,
-sam

Always pass referances not data structures hence \ operator is an optimistaion sub(\@array) instead of sub(@array)
Only use what you need from modules use CGI qw(:standard);
Also I like shortcut operators

my $i ||=0 ;
my $i =shift || 0;
[download]

also I like ? operator instead of if's

$i?$i=1:$i=0;
[download]

is !~ an optimisation over just negating the result of =~, I dunno but I think !~ looks better

Nah, no castigation here. When I whipped up my test, I had thought that the alphabet x 500 was a pretty big string, but now that I'm thinking clearly that's not very big at all.

To test out a really big string, I replicated Romeo and Juliet 500 times, read the whole thing into a string, then ran the same regular expressions almost the same regular expressions. I removed /o from the 'chars' sub, which actually made it a little faster. The string was about 70 MB. Here is my new test code:

use strict;
use Benchmark qw(cmpthese);

local $/ = undef;
open IN, "romeo-and-juliet-500-times.txt";
my $text = <IN>;
close IN;

# Ten iterations is enough with a 70 MB string!
cmpthese(10, {
  'i'       => sub { $text =~ /abc/ig },
  'chars'   => sub { $text =~ /[Aa][Bb][Cc]/g },
});
[download]

To my surprise (again!), the /i version ran in about 1/3 the time as the character-class version. Here is the output on my machine:

Benchmark: timing 10 iterations of chars, i...
     chars: 40 wallclock secs (38.37 usr +  0.04 sys = 38.41 CPU) @  0
+.26/s (n=10)
         i: 12 wallclock secs (11.43 usr +  0.01 sys = 11.44 CPU) @  0
+.87/s (n=10)
      s/iter chars     i
chars   3.84    --  -70%
i       1.14  236%    --
[download]

I'm amazed. Am I not testing the right thing? Or has /i really been cleaned up in recent versions of Perl? I'm running 5.6.1.

$foo vs "$foo" (don't interpolate when not needed)

I look at this as removing a pessimization, rather than introducing an optimization.

A lot of people say "$foo" because they have some experinece in c-shell or the like, where $foo == 'a' can turn into / == 'a' as opposed to '/' == 'a' which causes an error. I find it doesn't bug me as much as it used to.

 


______crazyinsomniac_____________________________ Of all the things I've lost, I miss my mind the most. perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

#!/usr/bin/perl -w
use Benchmark qw(cmpthese);
cmpthese (10000000, {
        single => sub { $foo = 'foo'},
        double => sub { $foo = "foo"}
        });
[download]

[jon@valium jon]$ ./test.pl 
Benchmark: timing 10000000 iterations of double, single...
    double:  1 wallclock secs ( 1.91 usr +  0.00 sys =  1.91 CPU) @ 52
+35602.09/s (n=10000000)
    single:  2 wallclock secs ( 1.25 usr +  0.00 sys =  1.25 CPU) @ 80
+00000.00/s (n=10000000)
            Rate double single
double 5235602/s     --   -35%
single 8000000/s    53%     --
[download]

What perl are you using? Those should be identical at runtime, since interpolation is converted to concatenation by the tokenizer. For evidence, try:

% perl -MO=Deparse -e '$foo=q(foo)'
$foo = 'foo';
-e syntax OK
% perl -MO=Deparse -e '$foo=qq(foo)'
$foo = 'foo';
-e syntax OK
[download]

I ran your benchmark program, and got +/- 3%. Try running it a few times.

I was logged in remotely to my home machine when i ran this, which means that xscreensaver was running with 100% of my cpu (yay OpenGL). I ran the test again without xscreensaver and i got the same results you did. oh well.

BlueLines

Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary.

I wonder if the results have anything to do with you using q instead of a single quote and qq instead of double quotes.

That is very odd. I get absolutely no difference with Perl 5.6.1:

            Rate single double
single 3937008/s     --     0%
double 3937008/s     0%     --
[download]

-sam

With 5.6.1...

On an otherwise unloaded P4 1.g GHz

1           Rate single double  2           Rate single double
single 4219409/s     --    -7%  single 4273504/s     --   -18%
double 4524887/s     7%     --  double 5208333/s    22%     --

3           Rate single double  4           Rate single double
single 4201681/s     --    -8%  single 4166667/s     --   -22%
double 4566210/s     9%     --  double 5347594/s    28%     --
[download]

On an otherwise reasonably loaded (0.31) sun4u

1           Rate double single  2           Rate double single
double 3079766/s     --   -18%  double 3054368/s     --   -11%
single 3763643/s    22%     --  single 3419973/s    12%     --

3           Rate double single  4           Rate double single
double 2866972/s     --   -18%  double 3107520/s     --   -10%
single 3495281/s    22%     --  single 3437607/s    11%     --
[download]

--
perl -pew "s/\b;([mnst])/'$1/g"

On an otherwise unloaded P4 1.g GHz

For certain very specific meanings of the word "unloaded", I'm sure. "foo" is optimized to 'foo' at compile time, so neither of them can possibly be faster. As you can see, the generated bytecode is equivalent:

2;0 juerd@ouranos:~$ perl -MO=Concise -e'$foo = "foo"'
6  <@> leave[t1] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
5     <2> sassign vKS/2 ->6
3        <$> const(PV "foo") s ->4
-        <1> ex-rv2sv sKRM*/1 ->5
4           <$> gvsv(*foo) s ->5
-e syntax OK
2;0 juerd@ouranos:~$ perl -MO=Concise -e'$foo = '\''bar'\'
6  <@> leave[t1] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
5     <2> sassign vKS/2 ->6
3        <$> const(PV "bar") s ->4
-        <1> ex-rv2sv sKRM*/1 ->5
4           <$> gvsv(*foo) s ->5
-e syntax OK
[download]

Even "Hello, $name!" is optimized to 'Hello, ' . $name . '!'.

Note: I _do_ think people should use single quotes when not interpolating. It saves you a lot of hits on the backslash key, and avoids getting bitten by: "$You're kidding me" (eq. "$You::re kidding me"), "my@emailaddress.com" (intended: "my\@emailaddress.com").

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.