# Category — cpan

## Smart Match – Speed comparison

Recently I was reading an article from the good folks at Perl Training Australia about the 5.10 Smart Match functionality. I was particularly interested in the fact that they referred to the speed of the Smart Match being “extremely fast”, so I decided to hack together a quick script to see what potential speed gains we were looking at.

I focused my investigation on comparing two arrays and using Benchmark to see how much quicker using the Smart Match would be.

I created two quick routines to compare the arrays:

```sub smart_compare {
return 1 if(\@a ~~ \@b);
}

sub foreach_compare {
return 0 if(@a != @b); #Scalar compare to check lengths.
my \$i = 0;

foreach (@a) {
return 0 if(\$a[\$i] != \$b[\$i]);
++\$i;
}

return 1;
}```

The smart match comparison being much more concise and the foreach_compare not having an particular optimisations, but both being fairly trivial.

So I chose four simple test cases for comparing the arrays:-

• Matching arrays (1,2,3,4,5,6) == (1,2,3,4,5,6)
• Last value different (1,2,3,4,5,6) == (1,2,3,4,5,5)
• First value different (1,2,3,4,5,6) == (5,2,3,4,5,6)
• Number of items in arrays different (1,2,3,4,5,6) = (1,2,3,4,5,6,7)

I was expecting the Smart Match to be quicker, although not by too much in all of the cases. It turns out that the Smart Match was slower in all but one case (Over a million iterations).

• Matching arrays (Smart Compare: 21 Seconds Foreach Loop: 7 Seconds)
• Last value differentÂ  (Smart Compare: 20 Seconds Foreach Loop: 6 Seconds)
• First value differentÂ  (Smart Compare: 5 Seconds Foreach Loop: 3 Seconds)
• Number of items in arrays differentÂ  (Smart Compare: 1 Second Foreach Loop: 1 Second)

When the number of items in the array is different the Smart Match and Foreach loop perform pretty much evenly across repeated tests.

All the tests were ran on Perl 5.10.0, installed from Source on a P4 with 2 Gig of ram. Whilst these findings show the smart match to be slower when comparing arrays, this is of course only a simple test case and other types of comparisons offered by the Smart Match should obviously be investigated too.

The test script is available for download if anyone wants to give it a go on their system (or find any mistakes).

## Perl: How did you get hooked?

One of the fine gentlemen I work with recently blogged about how he started out with Perl and it got me thinking about why Perl currently seems to be failing to drive the interest it so rightfully deserves.

Perhaps by thinking about how developers select a language we are more likely to understand why Perl doesn’t get the numbers. I personally can’t even remember how I started out on Perl, it was that long ago. I suspect it was because PHP wasn’t even around, and it was the most obvious choice for a dynamic site, or more likely page at the time.

So what are we doing to attract new developers to the wondrous Perl? CPAN offers a great resource for developers who already work with Perl, but what is there for developers new to Perl? Or more importantly what is there to actually entice them to Perl. Every virtual corner you turn someone is mentioning PHP or Ruby on Rails, but Perl seems to be less “down with the kids”.

Let me be the first to admit, I certainly don’t have the answers, but perhaps by looking at how we got the Perl bug, we can come up with some ideas how to hook in more users.

Recently on the Catalyst mailing list was a thread about the press release detailing the latest 5.8 version and discussions turned to the “outlandish claims” that PHP and Ruby evangelists make. But I find my self wondering do we do enough to actually proclaim the things that Perl does well?

Now I realise I’m ranting, but it’s entirely possible that I’ll need to be looking for a new job in the near future and I’m not entirely convinced I’ll be able to get one working with Perl. I’d love to be able to blame this on someone, but to be honest it’s entirely our own fault. As Perl developers we simply aren’t doing enough!

## Test::Aggregate

Test::Aggregate is a simple, yet fantastic module that allows, you guessed it, tests to be aggregated. This turns out to be a true god send when testing large Catalyst apps.

Previously in order to run all the tests against an app I would generally have ran a stand alone server in one terminal, and then ran the tests against that stand alone instance in another, something along the lines of:

```term1#> perl script/myapp_server.pl

term2#> CATALYST_SERVER="http://localhost:3000" prove -Ilib t```

Of course simply running prove t would run all the tests, but with the time taken to initialise the Catalyst instance being added to the start of each test, this could be hugely time consuming.

Using Test::Aggregate a very simple script can be knocked up that will run all your tests, and only actually create a single Catalyst instance.

```    use Test::Aggregate;

my \$tests = Test::Aggregate->new( {
dirs => 'myapp/t',
} );
\$tests->run;```

This will load all your tests, each into their own unique package space. Meaning that only a single Perl instance is required to run all the tests and that all the required modules will only be loaded once. Both the overhead in running the entire test suite and the execution time will be drastically reduced.

Problems can occur if you are using global variables, in that they may be overwitten by the tests as they run, but of course you aren’t using them anyway… are you?