Rating: 1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Why Perl Scripts are Super Fast? Benchmark Perl Scripts

Its quite evident that Perl Scripts runs super fast when it comes to handling regular expressions and text processing. Programmer usually argue over which programming language is fastest or better or supports more features but we need proofs and evidences to support any sort of claims. Lets try to determine why Perl Scripts runs extremely fast?
We can use Perl Benchmarking Module which let us test the speed of a Perl script.

Calculating differences in script execution time
Ideally we test speed by start time (When the script starts) and end time (When the script finished) and take the difference between the two values. This will become our script execution time. In Perl these time values are obtained with the built-in time() function:

While this is fine for basic use, it becomes complicated if what you really want is to compare the times of different scripts, or run arbitrary pieces of code for fixed time intervals. For these uses, the Benchmark module is more appropriate. This module comes bundled with Perl, and can be imported into your Perl script through the “use” command. Take a look at the next example, which rewrites the previous one to use Benchmark instead of time().

Every time you create a new Benchmark object with new(), the current time is returned. The difference between the start and end times is calculated with the Benchmark module’s timediff() function, and the result is formatted for display with the timestr() function. Here’s the sample output of the script above:

Time taken was 2 wallclock secs ( 2.14 usr 0.00 sys + 0.00 cusr
0.00 csys = 2.14 CPU) seconds

As you can see, Benchmark returns a little more detail than the time() function.

Timing multiple runs of a script

Of course, a sample size of one is not necessarily representative of how fast your script is, especially on Web servers that are subject to varying loads. Therefore, what you really need is a way to run this script many times, and calculate the average time taken after compiling the data from each run. Luckily, Benchmark comes with a function to do this too. It’s called timethis(), and it’s demonstrated in the following example:

The timethis() function accepts two arguments: the number of times to run the code block, and the code block itself. This code block must be provided to timethis() in a format suitable to the eval() function.

Once the benchmark is complete, timethis() displays a report like this:

timethis 100000: 210 wallclock secs (209.37 usr + 0.00 sys = 209.37
CPU) @ 477.62/s (n=100000)

There are two pieces of useful data here: the number of CPU seconds, which tells you how long Perl takes to run the code N times, and the per-second data, which tells you how many runs take place per second. Obviously, the higher the second value, the faster your code is. Instead of a fixed number of iterations, now let’s see how to have timethis() run the code for a fixed period of time.

Hide Counting how often a script runs in a predefined time window

Instead of timing how long a piece of code takes to execute a fixed number of iterations, you can flip things around and have timethis() run the code for a fixed period of time to see how many iterations it completes in that time. You do this by using a negative value as the first argument. Consider the following example, which makes timethis() run the code for a minimum of 10 seconds:

The output will look something like this:

timethis for 10: 11 wallclock secs (10.93 usr + 0.00 sys = 10.93 CPU) @ 700.82/s (n=7660)

So in 11 seconds (well, 10.93 if you want to be difficult), Perl was able to execute the code 7660 times, or approximately 700 times per second. You can even create an interactive benchmarking tool with timethis(), by having the user enter the code and the number of iterations at the prompt:

Most of this is pretty simple, and should be clear to you if you understood the previous examples. The only item of note here is the alteration of the Perl input separator to the code END, so that the user can enter multi-line code blocks and terminate them with the statement END (the default separator is a carriage return, which would make Perl jump to the next statement as soon as the user pressed [Enter]).

Here’s an example of this script in action (lines beginning with a ‘>’ indicate output from the program, the rest are lines input by the user):

> Enter number of iterations:
500
> Enter your Perl code (end with END):
for ($a=1; $a<1001; $a++) { $value = $a ** 10; } END > Processing…
> timethis 500: 6 wallclock secs ( 5.72 usr + 0.00 sys = 5.72 CPU) @ 87.41/s (n=500)

Timing and comparing different techniques

If you’re the kind of Perl programmer who likes experimenting with different ways of accomplishing the same thing, you’re going to just love the next tool in Benchmark’s arsenal. The timethese() function allows you to time more than one code fragment at a time:

This example tries to calculate the sine of 5,000 numbers, using three different approaches. The first, named “huey”, uses a while() loop; “dewey” uses a for() loop; and “louie” uses a foreach() loop. Each of these code snippets is placed inside a single call to the timethese() function, which accepts two arguments: the number of iterations and a hash whose values are the code snippets to be tested (the keys of the hash contain the unique names for the code fragments). The timethese() function then internally calls timethis() for each hash element and returns the time taken for each option. Here’s a sample of the output:

Benchmark: timing 1000 iterations of dewey, huey, louie…
dewey: 92 wallclock secs (91.72 usr +  0.00 sys = 91.72 CPU) @ 10.90/s (n=1000)
huey: 160 wallclock secs (159.56 usr +  0.00 sys = 159.56 CPU) @ 6.27/s (n=1000)
louie: 45 wallclock secs (44.98 usr +  0.00 sys = 44.98 CPU) @ 22.23/s (n=1000)

It is clear from the output that the foreach() loop is the most efficient of the three alternatives, at least for this particular scenario. Another way to run this test is with the cmpthese() function, which internally calls timethese(), and accepts the same arguments as timethese(). The main advantage is that it formats the result better for comparison purposes:

Note the use of “use Benchmark qw (:all)” instead of just “use Benchmark.” This ensures all the methods in the Benchmark object get exported. The output of cmpthese() is a table which compares the speed of each option against the speed of its competition. Since this table contains summary percentage values, it is somewhat easier to understand than the output of timethese():

Rate louie  huey dewey
louie 14.1/s    —  -50%  -54%
huey  28.5/s  102%    —   -8%

Leave me a comment and let me hear your opinion. If you’ve got any thoughts, comments or suggestions for things we could add, leave a comment! Also please Subscribe to our RSS for latest tips, tricks and examples on cutting edge stuff.

Related Posts

Substitution & Translation in Regular Expressions with Perl

Matching Regular expressions with Perl

Why Perl Complex Code requires less lines

How to Create Random Strong passwords with Perl

  • Thanks for the article. I have been breaking my head for years explaining PHP fans why Perl is much more stable, safer and faster then PHP. Here is a living example comparing WebAPP (a Perl based CMS) to drupal, wordpress etc etc (all which are PHP based CMS systems). http://www.web-app.net/?Fastest_Best_Most_Secur… See the results. It is shocking to learn that despite of the instability and CPU killing of PHP scripts, that the media is still giving them first prizes. I guess it has to do with a lack of competence when it comes to the target market of PHP.

  • Yossi if we are going to compare Perl and PHP then we have to take care of many aspects before making a statement on which one is faster. PHP owes a lot to Perl. PHP was first prototyped using Perl.

    BUT, Perl has a lot of deficiencies compared to PHP like:

    1. PHP is built from the ground-up with database functionality built in, particularly MySQL functionality. Perl is not.
    2. PHP code gets embedded into HTML pages, unlike Perl.
    3. PHP is secure. Perl scripts tend to have more security holes.
    4. PHP code tends to be more consistent and modular than Perl.

    On the contrary if we compare speed of execution then PHP takes less “overhead” than Perl, meaning that PHP scripts will run faster than CGI scripts written in Perl, and you’ll be able to handle more simultaneous users on your site. But Perl will lead the race if we compare the execution speed to handle regular expressions and text processing. But these are my takes on both the languages. Both the languages have their own advantages and disadvantages and its upto us which one to choose depending on the need.

  • Sam

    @Ashish: (May be Asish Jain)

    Note these things:

    1) Perl has best DBI-ORM (Rose) in the world followed by Python-SQLAlchemy

    2) Mod-perl is faster than PHP. (Nobody uses CGI-Perl much these days).we can also do PHP like embedding story in Perl using templating engines.

    3) Perl can be made more secure. Apache can be ripped full for any changes u want when using mod-perl

    4) OO-Perl is an add on feature but still is gr8 though it doesn't have Public, Private etc. by convention. But, other than for theoretical motives, there is not much use of these things. It just depends on how much you use ur head and feel happy that u declared a method/variable as private…since u can see it. Right ??

    Tweak mod-perl and u can see that you can indeed make perl have less overhead.

    Instead of saying the above comments u could have said that PHP is easier to use.

    Quote 1: “Easier things come at a price”
    Quote 2: “Free food is dangerous”
    Quote 3: “Perl is ultimate language ever discovered”

    Love,
    Sam

  • Random pissed BOFH

    > PHP is secure. Perl scripts tend to have more security holes.

    You _have_ to be joking. PHP's security record is the butt boy of the entire webdev world. Have the PHP folks clued in yet that parameterized queries are mandatory and why? Take a look at Secunia some time; any software in PHP is a big security risk.

    The Perl community, the Python community, even the Ruby community — hell _every_ community has a better security record than PHP, at least for SQL injection attacks. Maybe for other attacks too; pop quiz: what's a CSRF attack? I'd wager my next week's income that any non-PHP webdev is more likely to know the answer to that than a PHP one.

    I'm not a fan of Perl at all, but I am a sysadmin, and I've learned a deep loathing and distrust of PHP software as a result. The only PHP software we allow to run in our infrastructure — we have to since a boss insists on his fucking wordpress — is kept hidden on a single non-critical box with zero logical and physical access to any other system (we rent a box far from our network just for it), and everyone knows why.

    It truly boggles my mind that you're unaware of such universally-known knowledge. I'd be terrified of anything you write, man.

  • Random pissed BOFH

    > PHP is secure. Perl scripts tend to have more security holes.

    You _have_ to be joking. PHP's security record is the butt boy of the entire webdev world. Have the PHP folks clued in yet that parameterized queries are mandatory and why? Take a look at Secunia some time; any software in PHP is a big security risk.

    The Perl community, the Python community, even the Ruby community — hell _every_ community has a better security record than PHP, at least for SQL injection attacks. Maybe for other attacks too; pop quiz: what's a CSRF attack? I'd wager my next week's income that any non-PHP webdev is more likely to know the answer to that than a PHP one.

    I'm not a fan of Perl at all, but I am a sysadmin, and I've learned a deep loathing and distrust of PHP software as a result. The only PHP software we allow to run in our infrastructure — we have to since a boss insists on his fucking wordpress — is kept hidden on a single non-critical box with zero logical and physical access to any other system (we rent a box far from our network just for it), and everyone knows why.

    It truly boggles my mind that you're unaware of such universally-known knowledge. I'd be terrified of anything you write, man.

  • Many users prefer to use Linux server just because of perl

  • What are U talking about ?