Speed test: PHP vs Perl vs Python vs Go vs C

Recently I have needed to run a cron job every minute on a high load web server. As am currently most fluent in PHP I naturally wrote my script in PHP. However, as it’s running every minute, I do want it to be as fast as possible. Seeing as the script was very simple, I thought that the most time required to run is in loading the PHP interpreter. Maybe i could use a compiled language instead? What about Google’s new language Go?

NOTE: This was not an overall speed test. I am just trying to find out which approach would be fastest for running a cron job every minute. None of the programs tested run through a web server.

Anyway, for my test I wrote a “hello, world” command line app in each language and ran the program 1000 times. Without any further ado, here are the results, from fastest to slowest:

C: 5.37 seconds

Go: 6.23 seconds

Perl: 7.97 seconds

Python: 20.64 seconds

PHP: 41.31 seconds

There you go! PHP is a bit slow for this kind of thing! But I’m not going to write all my scripts in Go or C now (what a hassle!). So, for me…. perl wins!

Ahh, good old perl, my faithful friend! I will never forget you!

29 Responses to “Speed test: PHP vs Perl vs Python vs Go vs C”

  1. Greg says:

    Does your web server have mod_perl compiled into it? That could be the reason.

  2. hamish says:

    Greg, I’m not running any of these tests through a web server at all – only from the command line.

    Interesting point about mod_perl though – it reminds of when I switched from Perl to PHP for web apps years ago. PHP was so much faster because the interpreter was build into apache (mod_php). Perl had a horrible delay with each request as the perl interpreter had to be loaded with each request. mod_perl was the answer – but when i tried to port my apps to it – disaster! Not thread safe!

    When I get time I’ll run these simple hello world tests again through apache.

  3. Rahly says:

    Yes, running a script as a cron job, does not run through the web server. These are generally used for update/cleanup methods that run outside of the web server. Interesting about mod_perl though, is that most people tend to use the Registry method. I’ve found creating your own handlers to be way more efficient and fast. Plus, it gives you far more power over the entire request that you can’t get with PHP. You can do everything from programmatic url rewriting to remapping requests to specific files. For example, I wrote a handler that would handle file uploading in a more correct fashion, as it allows me to cancel posting while in progress. Something PHP can’t do, you have to wait until the entire post is done before your script fires.

    You are right though, about the thread safe. Although, most Apache installations are still MP and not MPMT or MT. Most scripts people write for Registry are not MP safe.

  4. Alex Libman says:

    There must be some per-process overhead with your Python binary that doesn’t exist with the Perl one… This overhead, which happens only once per script execution, is hardly significant unless you run a script many times per second. Start-up time aside, Python is generally a bit faster than Perl.

  5. Jpablon says:

    Phyton is not faster as Php, you are wrong. Maybe you have a bad compiled php version or some bad module.

  6. hamish says:

    Sure, why don’t you run your own trials and post the results.

    And remember people, I’m talking about command line scripts here.

    Can’t people read anymore or something?

  7. Very enlightening test. I would have thought C would win out, however for PHP to be 8 times slower is not encouraging.

  8. Wilsa S says:

    @PHP Programmer:
    Actually PHP being 8 times slower than C is wildly inaccurate, probably because this benchmark is heavily weighted toward I/O, which will blur the speed differences between languages. As far as the language goes, you can expect that C would be 50 – 80 times faster than an interpreter like PHP or Python.

  9. hamish says:

    Hi Wilsa,
    This was a real world test. How about backing up your ‘theories’ with some practical tests of your own before spouting out “wildy inaccurate” crap.

  10. Php says:

    The biggest advantage of PHP over Perl is that PHP was designed for scripting for the web, while Perl was designed to do a lot more. Because of this, Perl can get very complicated. The flexibility / complexity of Perl can make it difficult for developers of varying skill levels to collaborate. PHP has a less-confusing and stricter format without losing flexibility. PHP is also easier to integrate into existing HTML than Perl. In large part, PHP has all the ‘good’ functionality of Perl – constructs, syntax, et cetera – without making it as complicated as Perl can be. Yet PHP’s command-line interpreter (CLI) is powerful enough to perform high-level tasks much in the same way Perl has been traditionally employed. Perl is a very tried and true language, and has stood its ground since the 1980′s, but PHP has matured and evolved quickly, and continues to make fantastic progress.

  11. anon says:

    “PHP programmer” is quite an oxymoron.

  12. hamish says:

    Thanks anon… yeah y’know you’re obviously right – you are the only one true programmer out there. All honour to you.. king of the programmers. Now back into your little hole..tosser.

  13. Datamunger says:

    It seems that the new guidelines in Web 2.0 call for separating behavior from structure from style. With the re-emergence of Javascript(and jQuery), newer websites are not incorporating PHP into their HTML.

    Perl seems to be a much cleaner, stricter, and more powerful language than PHP. And I have worked with both.

  14. hamish says:

    You can separate structure and style in PHP too – if you want to. The thing about PHP is that you are free to do whatever you want. You can be OO – you can be procedural. You are FREE. If you dont like freedom then yes, choose a prison language like Python or Java or Perl or whatever ;)

    Languages don’t write bad code – people write bad code!

  15. scott says:

    I do not mean this as a personal jab, but this is not a valid speed test. Many people are not aware that printing to the screen is an Operating System call, not a feature of the language. The reason for variation may have to with constraints; such as a web-server processing the data printed out by PHP.

    A better speed test is held in categories such as: matrix multiplication, sorting, and mathematical computations like finding prime numbers.

    Your speed test basically comes down to this:

    do 1000 times
    call OS write function with “Hello World” to standard out file
    end
    process file with OS/Server

  16. hamish says:

    Scott, did you read my post? Or just skim read it? “Recently I have needed to run a cron job every minute on a high load web server” the speed test here includes starting up the interpreter. Because I am running a cron job every minute. This is not an overall performance test. This was a test to see which language was the fastest for this job. This was not an overall speed test. I was just trying to find out which approach would be fastest for running a cron job every minute. None of the programs tested run through a web server. They were all on the command line. This is not a web server speed test. This is not a general language speed test. This was a practical test to see which program would execute fastest for the purposes of a one minute cron job.

  17. scott says:

    I did end up skimming past some of those details. So, I would imagine the start-up and implementation of the interpreter would matter.
    I do agree with your idea that perl would be the best for the job as you described it.

  18. hamish says:

    No worries, Scott – who has time to read everything these days anyway? :)
    I’ve put the disclaimer in bold now!

    I’m going to include Ruby in the test too now…

  19. Sounds amazing hearing that PHP has taken 41.31 seconds. But the thing to be noted is we cannot do all tasks with C or Perl which can be ruled by PHP

  20. To what Scott said, I believe is part of a programming language to make OS calls, so, it is ok to me the performance test that was done to compare cronjobs execution time. My opinion, you use the language that fits the most to each specific task. For a web applicacion I would use PHP because the for web application PHP interpreter is compiled with Apache, which will help with the performance, for back end scripts and batch execution I would use perl… it all depends on what you like/know, what you need to accomplish and the environment(cli, gui, etc)

  21. ProDragon33 says:

    Has anyone tried Speedy::CGI for perl ?

    http://www.daemoninc.com/SpeedyCGI/

    This is an amazing module for Web or command line perl script. It creates a persistent image of the post-interpreter (compiled?) code in the memory, i.e the interpreter runs only once. You can specify the timeout when this image can be destroyed if not accessed.

    We have seen result improvements on repetitive run upto 1:10 on some heavy I/O + memory hogging scripts.

    Most of already written scripts can run under Speedy, however some attention must be given to permanent and volatile variables data by using ‘my’ and ‘our’ for variable declaration to avoid ambiguous variable state on next invoking of the script

  22. Pedro Amaral Couto says:

    time php -r “foreach(range(1000) as $i) { echo ‘hello world’; }”
    real 0m0.028s
    user 0m0.012s
    sys 0m0.012s

    time python -c “for i in range(1000): print ‘hello’”
    real 0m0.031s
    user 0m0.016s
    sys 0m0.008s

    time for i in {1..1000}; do python -c “print ‘hello’”; done
    real 0m21.730s
    user 0m14.997s
    sys 0m4.520s

    time for i in {1..1000}; do php -r “echo ‘hello’”; done
    real 0m25.197s
    user 0m13.913s
    sys 0m9.309s

  23. Fred Haegele says:

    Okay, I don’t know about this so-called “speed test”.

    I can get a simple PHP script to spit out 1000 “Hello Worlds” in less than one second. Same for Python. 41 seconds to do anything in PHP is a martal sin, and for this reason I question the skills of the programmer as well as the validity of the test.

    Of course, there is no way to know exactly HOW you came up with these numbers, since there isn’t one iota of code on here. SO I guess I’ll just have to take your word for it.

    In the meantime, I will be looking forward to your next benchmark with fibonacci numbers, as we all know how many people are looking for a scalable fibonacci-numbers-crunching app.

  24. hamish says:

    Hey Fred, read the post again, this time do it slowly and try and read all the words.

  25. joshua says:

    Lets do science. I will start. Here are my tests and my results. Please try and share.

    I had wanted to start using node for devops but it poor showing printing 1000 hello worlds is making me think twice. NOT! :D

    for i in {1..1000}; do php -r ‘echo “hello world “;’; done;
    46 seconds

    for i in {1..1000}; do php -r ‘print (“hello world “);’; done;
    42 seconds

    for i in {1..1000}; do perl -e ‘print “hello world “;’; done;
    28 seconds

    for i in {1..1000}; do python -c ‘print(“Hello world “)’; done;
    27 seconds

    for i in {1..1000}; do echo “Hello World “; done;
    3 seconds

    for i in {1..1000}; do node -e “console.log(‘Hello, world’);”; done;
    52 seconds

    for i in {1..1000}; do ruby -e ‘puts “Hello world “‘; done;
    5 seconds

    for i in {1..1000}; do echo ‘puts “Hello World “‘ | tclsh; done;
    16 seconds

  26. hamish says:

    Thanks for the post Joshua, you’re right – node may not be the most appropriate solution for running command line cron job tasks every minute

  27. joshua says:

    Lua ties with BASH:

    time for i in {1..1000}; do lua -e ‘ print(“Hello World”)’; done;
    3 seconds

  28. joshua says:

    WORST TIME = Groovy!

    time for i in {1..10}; do groovy -e “println ‘Hello world’”; done;
    31m26s

  29. woodydrn says:

    for i in {1..1000}; do php -r ‘echo “hello world “;’; done;

    Takes 8.4 sec for me – think you got a slow computer ;)

Leave a Reply