Ruby vs PHP performance

Update: February 1, 2009

Many people have pointed out that using count($a) > 0 in PHP is inefficient and should be replaced with !empty($a):

“In ruby while !a.empty? does not recount the array at every loop.
In php you do count the array each iteration which completely mistake the results…”

So PHP doesn’t store the array length, and a count() call iterates through the entire array just to find out the number of items?!?!?!

Leaving aside the issue that that’s kind of stupid of PHP, I’ve updated the code and the corresponding numbers and graph.

I’ve also re-run the benchmarks against newer software versions (Ubuntu 8.04) and newer Ruby implementations such as Ruby Enterprise Edition, Ruby 1.9 and JRuby.

It’s a well-known stereotype that “Ruby is slow”. People say it on Slashdot. People say it on OSNews. People say it on my MSN contact list. A few quotes:

  • “If you care even a little about performance, you don’t use Ruby.”
  • “You thought Python is slow? Well Ruby is even slower!”

Another stereotype we hear is that “Ruby on Rails doesn’t scale”. Most of the people who say that seem to use PHP, so they imply that PHP does scale.

How much of this is true? If there’s anything I’ve learned in the past few years, it’s that I shouldn’t always take public opinion seriously. PHP is not really a great language; its interpreter and perhaps even the language specification (if that even exists) has many quirks. My friend Ninh has worked on PHP in the past. He has exposed many of those strange quirks in his blog (which is, unfortunately, down because of a recent data loss incident).

I can’t imagine that PHP is faster than Ruby (the language; I’m not talking about Rails). If Ruby on Rails is slower than PHP, then how much of that is to blame on the language, and how much on the framework? Let’s put this to the test.

Goal of and rationale behind this test

We must first agree on the following premises:
People claim that Ruby is so slow that it’s impossible to build anything in it that’s sufficiently fast for “production environments”. (1)
Yet at the same time, they accept PHP as being fast enough. (2)

From (1) and (2) follows this question: Is it possible at all to write a web framework in Ruby that’s faster than PHP?

If (1) and (2) are true, i.e. if Ruby web apps are indeed slower than PHP web apps, then the culprit might be:

  • The web framework that the Ruby web app is written in. If this is the case, then it is possible to write a faster web framework that matches PHP’s performance. (3)
  • Ruby itself, i.e. the language. If this is the case, then it does not matter what web framework we use or how we write it, it will always be slower than equivalent frameworks PHP. (4)
  • A combination of both, in which both parts play a significant role. (5)

The goal of this benchmark is to find out whether (4) is true. (4) is what people have been arguing for years. And that’s assuming that people know what they’re talking about; they often don’t, and confuse the Ruby language with Ruby on Rails the framework, or even with web server Ruby integration modules.

Benchmarking PHP and Ruby (and Perl, Python, C++)

I want to benchmark PHP and Ruby’s code execution speed.

  • I specifically do not want to benchmark code parsing speed. Ruby on Rails apps run in application servers, so all code is only parsed once. PHP has stuff like PHP Accelerator/Zend Accelerator (or whatever those products are called) which cache the parse tree.
  • I’m not trying to benchmark HTTP request processing. This is only about code execution speed.

So, I decided to implemented the mergesort algorithm in PHP and Ruby. I’m not trying to benchmark sorting speed, but code execution speed. Both Ruby and PHP have builtin sort functions which are written in C, but that’s not the point. The scripts will sort an array of 100 numbers (which where randomly generated and hardcoded into the source code), and perform this sorting 3000 times. The execution times, in seconds, are as follows:
benchmark-with-mergesort.png
As you can see, I’ve also written a Perl, Python and C++ version just for comparison fun. :)

The sources code of the test programs can be found on the bottom of this blog post. A few notes:

  • Operating system: Ubuntu Linux 8.04
  • Hardware: Intel Core 2 Duo T5300 1.73 Ghz, 2 GB RAM
  • Versions:
    • PHP 5.2.4-2ubuntu5.4
    • Ruby Enterprise Edition 1.8.6-20090201
    • Ruby 1.9.1p5000 (2009-02-01 trunk 21929)
    • JRuby 1.1.7
    • Perl 5.8.8
    • Python 2.5.2
  • The test programs not only test raw CPU execution speed, but also memory management speed. As you can see in the merge() functions, it creates a new array, and modify the given arrays. As a result, the mergesort() functions will create a lot of objects that will have to be garbage collected.
  • Ruby uses a conservative mark-and-sweep garbage collector. Perl and Python both use reference counting. The C++ test program uses Boost’s shared_ptr, and thus uses reference counting for memory management. I’m not sure how PHP manages its memory, or whether it does it at all, because all objects are freed after an HTTP request anyway.
  • The C++ test program is compiled with g++ 4.2.4, with -O2.
  • By using Psyco, a JIT optimizer for Python, the Python test program’s execution time went down to a whopping 0.640 seconds. That’s even faster than my C++ version (!)

But as you can see in the graph, Ruby beats PHP marginally even with a full-blown mark-and-sweep garbage collector. Ruby’s garbage collector was run several dozens times while running the test program, and Ruby still beats PHP in execution time.

Ruby 1.9 and JRuby are significantly faster than PHP, beating even Python.

I have no choice but to conclude that all the “Ruby is slow” stereotypes are bollocks. PHP the language is slower, yet we do not see anybody complaining about PHP “scalability”. The Rails framework could be faster, yes, but at least now we know the language is not as big as a bottleneck as some people might think.
Wait! Do I see a flame thrower there? Read on before you reply!

“But but but… you didn’t benchmark the web environment!”

Yes. I did not benchmark the HTTP request handling, and this is intentional. People claim that Ruby is so slow, that it is impossible to write anything in it that’s acceptably fast. This benchmark proves that, as a language, Ruby is faster than PHP. Therefore, if people can write frameworks in PHP that’s acceptably fast, then it is also possible to write frameworks in Ruby that’s acceptably fast.

Note that I do not make any claims about Ruby on Rails’s speed compared to typical PHP applications.

“Why don’t you use the language’s builtin sort function? This benchmark is crap!”

Implementing sort in the languge instead of using the builtin sort function is intentional. The goal of the benchmark is to test *code execution speed*, not to find out which language can sort faster. This benchmark is a good test because it tests different language primitives, like function calls, comarison operators, arrays, etc. I might as well have implemented A* graph searching, but mergesort is easier.

Appendix: Source codes

80 Comments »

  1. rubynho said,

    January 17, 2008 @ 6:55 pm

    I’ve run the Ruby benchmark using the different Ruby interpreters, and I wrapped the loop for benchmark like this:

    require ‘benchmark’
    puts Benchmark.measure{
    3000.times do
    mergesort(numbers)
    end
    }

    Here’s the promising future of Ruby:

    $ ruby merge_sort.rb
    7.520000 0.520000 8.040000 ( 8.307699)
    $ ruby1.9 merge_sort.rb
    2.830000 0.030000 2.860000 ( 2.951124)
    $ jruby -J-server merge_sort.rb
    4.882000 0.000000 4.882000 ( 4.746000)

    Cheers.

  2. For You Ruby Startups « nPost Startup Blog said,

    January 17, 2008 @ 7:34 pm

    [...] You Ruby Startups Some good news. The age old question has been answered (or has it), is Ruby faster or slower than PHP?  Spoiler, Ruby is [...]

  3. Erik Peterson said,

    January 17, 2008 @ 8:49 pm

    My comment before got screwed up because the less than sign was not escaped. Boo! Let’s try it this way instead:

    This is probably besides the point, but if you take advantage of common ruby idioms, you can compress the code by an order of magnitude, while reducing runtime by about 50% (which makes it about even with Python and Perl):

    http://pastie.caboo.se/140178

    While I’m sure the same kind of compression could be applied with Python and Perl, this just exemplifies that language power is just as important as language speed.

    And, as was already noted, Ruby 1.9 will speed up these numbers dramatically.

  4. Hongli said,

    January 17, 2008 @ 9:57 pm

    Erik Peterson: I know. But I intentionally avoided such idoms. I wanted the test programs to be as identical as possible.

  5. DieLaughing said,

    January 17, 2008 @ 10:47 pm

    Yeah, it’ll mergesort, but does it blend?

  6. Abhay Kumar said,

    January 17, 2008 @ 10:53 pm

    It’d be nice to see the idiomatic versions of all those code snippets put up against each other.

  7. Hongli said,

    January 17, 2008 @ 11:22 pm

    RayNBow said:

    Here’s a naive Haskell version:
    http://pastebin.ca/859068

    Compiled version:
    RayNbow@Freedom /cygdrive/d
    $ time Main.exe
    MergeSort benchmark in Haskell
    Done!

    real 0m0.529s
    user 0m0.031s
    sys 0m0.000s

    Interpreted version:
    *Main> :s +s
    *Main> main
    MergeSort benchmark in Haskell
    Done!
    (3.03 secs, 326678284 bytes)

    the Haskell code ran on a P-M 2.23 Ghz, single core, 1 GB of RAM, under WinXP using GHC 6.8.2.

  8. zik said,

    January 18, 2008 @ 12:17 am

    Sorry, but this is bogus.
    If you have to sort an array in php you do it like this:

    sort( $numbers );

    Changing the contents of the loop to:

    $arrayCopy = $numbers;
    sort($arrayCopy); // sort works on the array itself

    results in ~60x performance (on my box).

    It is similar to benchmarking perl’s string parsing performance by implementing a state machine that consumes strings char by char instead of using perl’s builtin regex support.

    The point is, this benchmark means nothing for real applications (only poorly implemented ones).

  9. Hongli said,

    January 18, 2008 @ 12:32 am

    zik, implementing sort in PHP instead of using the builtin sort function is intentional. The goal of the benchmark is to test *code execution speed*, not to find out which language can sort faster. This benchmark is a good test because it tests different language primitives, like function calls, comarison operators, arrays, etc. I might as well have implemented A* graph searching, but mergesort is easier.

    “It is similar to benchmarking perl’s string parsing performance by implementing a state machine that consumes strings char by char instead of using perl’s builtin regex support.”
    If the goal is to benchmark Perl’s string parsing performance, then yes it is stupid. But if the goal is to benchmark Perl’s ability to handle individual characters in a string, then it is a good benchmark. Again, the goal of my benchmark is *not* to benchmark sorting performance.

  10. RayNbow said,

    January 18, 2008 @ 12:56 am

    Heh, didn’t notice comments should be here.

    Anyway, @zik:
    Most benchmarks are pointless, as their scope is very limited. Performance heavily depends on the compiler/interpreter, hardware and used algorithm.

    The main point of this blog post was to show how well Ruby performs in a mergesort situation. As you can see, all the implementations share the same structure and are using the same algorithm. In this specific situation, it does show that Ruby is faster than PHP.

    It is true that this is not a real application, but what is? No one in the world would be mad enough to develop two real applications in two different languages and then compare the performance between the two.

    About using the built-in PHP function sort, well, isn’t that a bit cheating? ;) First of all, I have no idea what kind of sort it performs. It might be mergesort, but it could also be some other algorithm (quicksort for example). Secondly, the reason why the PHP implementation does not use the built-in function and instead uses a similar approach as the other versions is to have a fair comparison. Now all the different implementations have roughly the same amount of function calls, roughly the same amount of memory allocations and freeing, and so on… The differences in execution times can then be correlated to how fast a certain interpreter or compiled code can perform one of these basic tasks.

    To allow built-in functions like PHP’s sort to be used, you would need a different benchmark. The benchmark would have to be more like a real world application (i.e., it should be doing something useful that takes some considerable amount of time). In such a benchmark, however, you are no longer benchmarking the raw computing power of a language’s interpreter or a compiled binary, but instead your benchmark’s focus is shifting towards the performance of the implementation of the language’s standard library, which is not necessarily written in the same language. So essentially, such a benchmark’s results would then be more of an indication of the ease of writing performant code, rather than the performance of the interpreter or compiler itself.

    Anyway, the blog post was to show that Ruby is not slow in certain, equivalent situations. It was an attempt to make the “Ruby is slow FUD” (Fear, uncertainty, and doubt) go away. Ruby probably has to go through the same hell as Java. ;)

    To conclude this comment, I will quote a relevant, old post from GameDev:
    “I find it somewhat ironic that a few years ago when C++ benchmarks were beating Java benchmarks the response was always “But that’s a microbenchmark – Java will be faster in real world applications”. Now we’ve got Java benchmarks outperforming C++ benchmarks (for some time now) and the response is “But thats a microbenchmark – C++ will be faster in a real world application”.

    Fun. :)”
    [ http://www.gamedev.net/community/forums/topic.asp?whichpage=2&pagesize=25&topic_id=333765 ]

  11. Frank Leahy said,

    January 18, 2008 @ 3:28 am

    You’re using count($a) and array_shift() inside of your PHP loops — neither are needed. I was able to speed the PHP code by a factor of > 2 (from 23 seconds to 10 seconds on my MacBookPro) with a couple of minor changes. Here’s my version:

    function merge(&$a, &$b)
    {
    $c = array();
    $numA = count($a); // $b[$ptrB])
    $c[] = $b[$ptrB++];
    else
    $c[] = $a[$ptrA++];
    }
    while ($ptrA

  12. Frank Leahy said,

    January 18, 2008 @ 3:29 am

    Blog ate my code…trying again

    function merge(&$a, &$b)
    {
    $c = array();
    $numA = count($a); // <== don’t call count() in loop
    $numB = count($b);
    $ptrA = 0; // <== don’t need to use array_shift
    $ptrB = 0;
    while ($ptrA < $numA && $ptrB < $numB)
    {
    if ($a[$ptrA] > $b[$ptrB])
    $c[] = $b[$ptrB++];
    else
    $c[] = $a[$ptrA++];
    }
    while ($ptrA < $numA) {
    $c[] = $a[$ptrA++];
    }
    while ($ptrB < $numB) {
    $c[] = $b[$ptrB++];
    }
    return $c;
    }

    function mergesort(&$a) {
    $n = count($a);
    if ($n <= 1) {
    return $a;
    }

    $l1 = array();
    $l2 = array();
    $i = 0;
    $halfWay = $n / 2; // <== don’t calc in while()
    while ($i < $halfWay) {
    $l1[] = $a[$i++];
    }
    while ($i < $n) {
    $l2[] = $a[$i++];
    }

    $l1 = mergesort($l1);
    $l2 = mergesort($l2);
    return merge2($l1, $l2);
    }

    $numbers = array(47448054, 1106251565, 1208921855, 170086026, 840395770, 444281018, 1297307905, 1613614128, 357068250, 1829657695, 654555439, 1261773796, 1821640729, 449683981, 1062536538, 96076061, 1387478498, 1835855315, 364455615, 4830124, 864633601, 289493189, 471351435, 435996916, 1366312031, 888420407, 1923379522, 735726044, 1094401518, 245520239, 109946712, 1107893495, 592868510, 700148765, 273016388, 343881444, 420725947, 1259049694, 1692920986, 71271532, 1154617350, 593508009, 1106700528, 430204045, 1045928775, 1330476642, 49983990, 1451164767, 1175404600, 644832496, 365016297, 1048732794, 503615317, 217186301, 1176160338, 1183622513, 81711049, 1720671278, 1393072097, 1315236388, 1451774341, 92848458, 271000544, 1667871288, 380233084, 1053079658, 1249341507, 1276652307, 1722015039, 1243698025, 178813868, 1449271074, 1994327579, 270972819, 1043379189, 1592595484, 462468972, 1464773315, 1994172406, 997300623, 46405283, 1614271949, 447907123, 317292284, 378291676, 1253835093, 523476912, 1606023999, 59263848, 1234358080, 140981643, 1828471854, 1197394207, 1317927546, 878287915, 334576359, 982149842, 642878238, 1024064999, 1834342299);
    $start = time();
    for ($i = 0; $i < 3000; $i++) {
    $t = mergesort($numbers);
    }
    print(time() – $start);

  13. ara said,

    January 18, 2008 @ 5:58 am

    wow! trully Ruby is faster than PHP.
    thanks for the info.

  14. pcdinh said,

    January 18, 2008 @ 8:25 am

    I am sorry to make you sad but your approach is seriously flawed. Ruby can be faster in some loops or some very basic functions but indeed slower when it comes to production-grade features. Have you ever developed Ruby-based web pages (not using Ruby on Rails) and deployed them in a shared host? I dare to say that you will see the difference.

    Ruby is slow by design because Ruby has a lot of nice features that PHP does not have and PHP core developers do not want to add them into PHP due to performance downgrade.

  15. Hongli said,

    January 18, 2008 @ 9:47 am

    Frank Leahy: The fact that it shifts the array is intentional. I wanted to test array shiting performance as well as memory allocation performance. If you want to “optimize” that part, don’t forget to optimize the other test programs in the same way as well, or it won’t be a good test.

    pcdinh: Please read “Goal of and rationale behind this test” which I had just written.

  16. 「2007年に一番伸びた言語はPython」とスクリプト言語の速度比較 | テクトリム said,

    January 18, 2008 @ 11:25 am

    [...] via ZDNet Japan via Elliott C. Back via 赖洪礼的 blogC++ java perl php python ruby software スクリプト言語 ニュース 速度比較 [...]

  17. RayNbow said,

    January 18, 2008 @ 11:52 am

    I noticed that my previous Haskell version actually did not correctly merge two lists. So here’s the correct version: http://pastebin.ca/859696
    (I really should be using quickcheck :p)

    New compiled version took about 0.271 to 0.587s, although this time I used the -O2 flag:
    $ time Main.exe
    MergeSort benchmark in Haskell
    Done!

    real 0m0.385s
    user 0m0.015s
    sys 0m0.031s

    Although without the -O2 flag, average times are slighlty better, heh…

    New interpreted version is slower, most likely because during runtime the expression graph contains more nodes that have to be reduced:
    *Main> :s +s
    *Main> main
    MergeSort benchmark in Haskell
    Done!
    (4.48 secs, 450504368 bytes)

  18. PHP compared to other languages... - TalkPHP said,

    January 18, 2008 @ 2:03 pm

    [...] are a few articles that I would like some of the advanced users here at TalkPHP to comment upon: ???? blog Ruby vs PHP performance PythonVsPhp – PythonInfo Wiki I have heard a lot of good things about Python (namspaces,OO, et [...]

  19. Pádraic Brady said,

    January 18, 2008 @ 6:23 pm

    Coming from both a PHP and Ruby user… Seriously, this is just a ridiculous benchmark. Why NOT use PHP’s and Ruby’s leanest possible implementation of mergesort and then run the benchmark? Then at least you’re testing something relevant… This is just a faddish benchmark based on a construct no sane PHP developer would ever use. Of course it’s going to be slower if you refuse the leverage the language as it was written. You think the PHP devs added sort() for a laugh? Or to be utilised?

  20. Hongli said,

    January 18, 2008 @ 6:33 pm

    Pádraic Brady, please read “Goal of and rationale behind this test”. I didn’t write that for nothing after all.

    Benchmarking sorting performance is an *explicit non-goal* of this test. The goal is to find out who can perform language primitives faster, not who can sort faster.

  21. RayNbow said,

    January 18, 2008 @ 7:34 pm

    To all the people that are complaining that the benchmark is not fair:

    If the goal of each program was to just sort a list and do nothing with the sorted list, then I could write a Haskell program that would finish in a blink (and end up as #1 of the benchmark). Haskell is a lazy language, so it tries to do the least amount of work possible. If it sees you’re computing the same expression twice, it will only compute it once. If it sees you’re not using an expression, it will not evaluate it at all.

    Now, if I proposed such a Haskell implementation that actually does not even bother to sort the list of numbers 3000 times, would you accept that Haskell was a damn fast language? Most likely not and you would be saying my program would be cheating.

    Instead, I tried to jump through a few hoops trying to get Haskell to actually perform mergesort 3000 times. I did this by making sure every list to be sorted was slightly different (by prepending an increasing number to the list), so that the 3000 mergesort expressions could not be seen as 3000 identical expressions. Furthermore, I made sure every element of a sorted list would be evaluated. There are several ways to do this, but I chose to just compute the minimum value of each sorted list. Then to make sure that the minimum value of each sorted list would be computed, the program contained an expression to compute the minimum value of these values. To make sure that this minium value of minimum values would be computed, the program compared this to be computed value with a numeric constant.

    Now, my Haskell program is actually doing *more* than the PHP and Ruby implementations. It sorts 3000 different lists that are 1 element larger than the list that is sorted in the other programs. It also computes the smallest element in the sorted lists. And yet, my (naive) Haskell program is still performing damn well. ;)

  22. Arjen said,

    January 19, 2008 @ 2:29 pm

    Hongli: I agree that the tests should be as similar as possible and that the actual function doesn’t really matter for this benchmark’s goal, as long as you’re doing the same thing in each language. But Frank’s post does point out that you may not have kept the programs similar enough.

    Doing four counts in three loops isn’t really fair if you use a non-counting solution in your the main competiter. If I use your ruby and php examples, I get 7.8 seconds for PHP and 5.6 for Ruby. If I, however, change your while-loops in php from reading “while(count($a) > 0 …) to “while(!empty($a) …” and leave all the rest the same, PHP only uses 3.9 seconds.

    And I think that that small change to the code even makes it more similar to the Ruby-variant of your code.

  23. BLOGems » Archivo del weblog » Volverse ágil: ¿poco a poco o de golpe? Y dos gemas said,

    January 20, 2008 @ 11:13 am

    [...] o Ruby, ¿quién corre más? Un blogero ha realizado un pequeño experimento para medir la velocidad de ejecución -en segundos- del código PHP y Ruby. También ha incluido [...]

  24. regeya said,

    January 21, 2008 @ 4:23 am

    A while back I took a simple Perl password generator and rewrote it in Ruby. Then I obsessively chased performance bottlenecks. I managed to get acceptably comparable performance (it was still slower than Perl, natch) and learned a couple of things:

    1. There’s a reason Ruby’s being largely rewritten for performance, but Ruby’s not absolutely horrible. Rethink your problem in terms of Ruby’s strengths and limitations, and you will be richly rewarded.

    2. After looking at the code of both projects, despite the current poor performance of Ruby, I much prefer the Ruby solution. I can actually read it! It took some head-scratching to understand even a 20-line Perl script (though admittedly I’m not a coder by trade.)

  25. Mgccl said,

    January 22, 2008 @ 5:58 am

    Well I am not a master of all language… but….
    is ruby really faster?
    is those 2 source really the exact same code implemented in 2 different languages?
    or there are a few differences because ruby and php handle things differently? so PHP is actually doing way more work?
    and… is this the only benchmark in the world showing ruby is faster at one single area? is there any other benchmarks ruby out place PHP?
    I would really like to see that.
    If anyone really want performance….
    built your own specific chip and hardware just for this single merge sort job, get rid of all useless CPU instructions(addition, subtraction? puff, merge sort don’t need them), flags and other crap…I bet a 500MHz specialized merge sort system can out perform fully optimized ASM merge sort on any generic PC available today. but yeah… it can not do anything else.
    of course.. that’s like totally not sensible…people created programming language for convince… so in my opinion… if it works and the speed is accept able… get over it…
    and yes, there are specially made chips, heard of deep blue before?
    I would use ruby if it’s as popular as PHP…
    I would use perl if I am a sys admin…
    I would use python if I actually have need of it…

  26. AllIPTech » Blog Archive » Ruby vs PHP Performance Revisited said,

    January 25, 2008 @ 3:12 pm

    [...] any of Hongli Lai’s actual code, I reran the PHP, Ruby, C++, Perl, and Python mergesort benchmarks he gave, and came up with [...]

  27. retry said,

    January 26, 2008 @ 3:59 am

    http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=php&lang2=ruby

    nuff said…the only thing php is slower on is startup and that don’t matter in a web environment if you don’t use standard CGI (nobody does)…

  28. retry said,

    January 26, 2008 @ 4:01 am

    oh and in a web idiom, php has opcode caching (more speed)…also the ram consumption of RoR sky rockets with mongrels…

  29. retry said,

    January 26, 2008 @ 4:02 am

    I’m tired of rubyfag lies…

  30. Ninh’s Weblog » Blog Archive » Coming Up Next… said,

    January 27, 2008 @ 12:19 am

    [...] A performance benchmark between PHP MVC frameworks and Rails as a supplement to Hongli’s benchmark with regards to PHP vs Ruby. [...]

  31. Brian Parsons » Blog Archive » PHP vs Ruby vs Python vs Perl said,

    January 28, 2008 @ 4:02 pm

    [...] on pure language parsing Ruby is faster than PHP according to this study. This makes sense because Ruby is young and not yet bloated. The bloat will come just like the [...]

  32. carakan | web 2.0 y otras cosas. » Noticias cortas said,

    February 1, 2008 @ 6:10 pm

    [...] lenguaje de programacion Ruby es mas rapido que PHP, es lo que afirman en este blog, el cual haciendo una prueba con mismos problemas y resuluciones para cada tipo de lenguaje es una [...]

  33. James Socol said,

    February 5, 2008 @ 2:45 am

    I wasn’t going to say anything, since Arjen already already did, but with so many people citing this article I have to speak up.

    You’re not implementing the same code. Either replace the “!a.empty?” with “a.length > 0″ or replace “count($a) > 0″ with “!empty($a)” and you’ll have a valid test. Otherwise you’re handicapping one of the competitors before they even start the race.

    I did 10 trials of the PHP version with both “count” and “!empty” and using “!empty” is 50% faster. A 50% speed increase in PHP reverses your result.

  34. great said,

    February 6, 2008 @ 6:26 pm

    Indeed replacing the count( ) with !empty( ) cuts the PHP example’s performance by half. Interestingly, running the ruby example under ruby v1.9 cuts the ruby example’s performance to be faster than the modified PHP example.

  35. Egon_Freeman said,

    February 17, 2008 @ 12:04 pm

    I must say this isn’t exactly an eye-opener. ;-) Although I still preffer PHP to any language out there.

    What is weird, I write PHP code for stand-alone, memory-resident apps (ie. merging it into .exe files). The downside? I must use PHP4. But what they hey. :-) Speed isn’t something I need PHP for – I love the amount of built-in support for things I would have to do by hand in, say, C or C++. Of course, if You need speed, C is the way to go, but… ;-)

    The unmodified code on PHP4->exe ran for about 44 seconds (Athlon64 2 GHz, 2GB SDR, Win2003 Server with app-profile set on ‘background services’). Switching from count() to !empty() indeed did cut it in half (25s). But like I said, it’s not speed I’m looking for. :-) Besides, when I really need speed, there’s a handful of functions I can use, or write my own extension to support one in C… Most bottlenecks come from idiotic code design in the first place.

    I must say – people are weird that way, Y’know? I mean, learn the strengths and weaknesses of your language of choice, and THEN argue about it. Is there any point in comparing execution time/speed between PHP and, say, C? No, because they’re used for wildly different applications. There is no lnaguage that I could say would have “truly all” – functions, compatiblity, speed and ease of use. PHP can be used straight out-of-the-box, to get the same functionality in C one’d have to spend YEARS writing libraries. But then – C is faster than PHP, and understandably so – exactly because it comes as a ‘bare’ language, where one has to do all by hand from the get-go. So, people – stop waging religious wars about this stuff, and get back to writing good code. With the extra time, maybe we’ll see some REALLY good code… don’t Ya think? ;P

    And oh, about PHP’s garbage collector – PHP uses reference counting in ZVALs.

  36. PHP vs Ruby speed test said,

    February 24, 2008 @ 10:43 am

    [...] recently found a post on this one particular blog that was doing benchmark for PHP vs Ruby.  The author of the blog wrote merge sort in PHP, Ruby, Perl, Python and C++, then proceeded [...]

  37. lopex said,

    February 24, 2008 @ 5:40 pm

    Tried jruby1.1/ruby19/ruby18 (all trunk)
    To let the jvm warm up, run the mergesort twice in the same script. Here are the timings after second pass:

    jruby: 2.128
    ruby1.9: 4.144
    ruby1.8: 9.625

  38. Steffen Wendzel said,

    February 27, 2008 @ 12:05 am

    can someone provide php6 performance information on this test? it would be very interesting to have this information too. thanks for the performance test so far.

    –steffen

  39. Alex said,

    March 27, 2008 @ 9:01 pm

    That’s Jack of all *trades*, not traits. That would be a horse of a different color…

  40. Andrew Vayanis said,

    April 8, 2008 @ 10:26 pm

    I didn’t read through everything, but have you looked at http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all for a comparison in execution speed? A mergesort shootout is far from conclusive.

    - Andrew

  41. Nuno Luciano said,

    April 15, 2008 @ 10:31 am

    PHP vs Ruby vs Perl vs Python vs C++
    [.. Check the surprising execution times, in seconds,here..]

  42. Tech Messages | 2008-04-19 | Slaptijack said,

    April 20, 2008 @ 1:35 am

    [...] ???? blog » Ruby vs PHP performanceIf you are interested in programming benchmarks, this article also includes Perl, Python, and C++. [...]

  43. Xeno said,

    April 29, 2008 @ 9:33 pm

    ineffective test. As described by Rasmus Lerford, PHP is a web development language. As such isn’t buil for CLI or anything else. So when processing scripts, it actualy has to start the engine and shut down each time the script triggers unlike the other languages which are made to be used as a CLI. So treating PHP as a CLI for this test natuarlly will give you flawed results.

    To be fair, you need to either install the PHP as a CLI or run it as an Apache module so that the engine stays up and running so that it can be run on the same level as the others. In which case you will notice that the speed will actually decrease to half of what you are seeing which is far below RUBY.

  44. Hongli said,

    April 29, 2008 @ 10:23 pm

    Xeno, the test *was* run from the CLI…

  45. Neil said,

    May 5, 2008 @ 9:02 pm

    Hongli, clearly you are a supporter of Ruby, so this test is pretty biased, so the value becomes suspect. It seems likely that searched for a particular set of tests that Ruby would out-perform PHP in and then publish a general result that Ruby is faster.

    There is already a generally accepted unbiased language benchmark out there – http://shootout.alioth.debian.org/ I’m sure you don’t care for it as Ruby performs more slowly than PHP and Python.

  46. mx_ said,

    May 12, 2008 @ 5:49 pm

    Hogli,

    Arjen pointed out the biggest flaw of your test. I’m not rooting for either language, I’m using both where appropriate. However using php’s count() on every loop iteration so many times is a horrible mistake, which renders the benchmark meaningless. I suggest updating your tests (and some of the conclusions).

  47. Chris said,

    May 21, 2008 @ 8:28 pm

    Hello

    I’ve think your benchmark is not very good. When you use the http://eaccelerator.net/, than is php a lot of quicklier!

    Please make your benchmark with a correct live enviroment

  48. alex said,

    July 2, 2008 @ 6:22 pm

    This benchmark is false. The only thing that this bench proves is the lack of knowledge of the author.
    In ruby while !a.empty? does not recount the array at every loop.
    In php you do count the array each iteration which completely mistake the results…

    Just take the count out of this and use two integers and the time is divided by two which make php still faster than ruby.

  49. alex said,

    July 2, 2008 @ 6:59 pm

    Did you know that php too has a empty function that you can use ?

  50. jERRY said,

    July 5, 2008 @ 6:37 am

    All I know is all the Ruby on Rails stuff I’ve developed for has been slow as molasses…
    the same apps implemented in PHP, faster than a greased squid.

    Real world:
    PHP 1
    Ruby 0

    Coolness factor:
    PHP 0
    Ruby 1

  51. michael depetrillo said,

    July 6, 2008 @ 9:22 pm

    Your PHP script is seriously flawed. You shouldn’t use count() in a while loop or the array will be unnecessarily recounted during each iteration.

  52. sammy said,

    July 17, 2008 @ 1:24 pm

    Surprise! I wrote the perl code for the sort mentioned above (TMTOWTDI). I achieved better speed than Python. Perl is the good for most things we can imagine of. Modperl is wonderful beyond words. Perl’s downside are weird syntax and sucking catalyst framework.

    The author of this post clearly proves that Ruby is fast as a language (But the language’s popular framework is slow.)

    Thinking further !?
    ————-

    a) Ruby
    ——-
    1) Ruby on Rails is heavier but an eye-opener framework for all of us
    2) Since, Ruby is fast as a language, we need to use lighter frameworks like merb along with DataMapper for top speeds
    3) Ruby’s library completeness,documentation and licensing issues are to be taken into consideration before starting a project

    b) Python
    ——–
    1) Python is moving up in popularity but the language is still slow for my day-to-day work. I tried with PyPy, Pyrex, Psyco but had much difficulties converting OOP code to Pyx file. So, the applicability of these modules is still experimental. The speed I got using these modules for an application that reads and parses XL data was still lesser than my normal perl version. Also, in perl version I don’t care about C language, conversion issues etc. all. and thus less sweat and fast prototyping.
    2) Django is great. It’s the best in the world. (My Rating–u may disagree:-): Django>ROR>Pylons>TGears>CakePHP>CodeIgniter>Symphony

    c) PHP
    ——
    1) Does everything/anything for me but is still slow for algorithms and large datasets. So, I use it with control for large projects.
    2) Not much third party modules for heavy calculations, graphics (Obvious due to short life of web page)

    d) Perl
    ——
    1) I write legible/Maintainable code in perl. Develop webapps with Modperl but hate catalyst framework. Mason based templating is nice but I create small files that serve as templates for my small needs. Thus I bypass Mason, Catalyst and yet obtain top speeds.
    2) Perl is the fastest language in web domain that needs to be well written (very much possible to write legible code) or else we have red eyes to understand what we wrote.

    Love all,
    Sammy

  53. CaViCcHi said,

    August 22, 2008 @ 1:13 am

    What I really think is that u should choose a language according to their functionalities…
    I really trust C/PHP when we are talking about fsockopen and API communications, if you are talking about echo or print… then why are you using php or ruby? just get back to bare ASP…

    Sorry but this benchmark is really not important, and the information it provides are useless… if you know how to write code and how to make it work really sharp, then u don’t even need to change your language. I don’t really know why every programmer is called so when uses someone elses framework, guys you should develop your own libraries and then use them… so you can cut time in developing!

  54. 50个非常有用的PHP工具 | 胡言乱语 said,

    January 21, 2009 @ 9:26 am

    [...] PHP是使用最为广泛的开源服务器端脚本语言之一,当然PHP并不是速度最快的,但它却是最常用的脚本语言。这里有50个有益的PHP工具,可以大大提高你的编程工作: [...]

  55. Sean Grove said,

    January 21, 2009 @ 11:51 am

    Interesting article, thanks for this.

    Not sure what he difficulties are for others to understand your methodology. Given the same series of instructions/low-level tasks with roughly equal optimizations, how does each language perform.

    Thanks for the read!

  56. Stephen Bannasch said,

    February 5, 2009 @ 12:54 am

    Hongli,

    I wrapped your mergesort code in Ruby’s benchmark library and did a more detailed comparison of 1.8.6, 1.9, and JRuby running on Java 1.5, 1.6, and 1.7.

    http://blog.concord.org/archives/24-Comparison-of-Ruby-1.8.6-1.9-and-JRuby-running-on-Java-1.5-1.6-and-1.7.html

    Using the Benchmark library and running a “rehearsal” before the main measurement results in better timings for JRuby because the JVM ends up optimizing the code that is run the most.

    The fastest “safe” result shows that JRuby running on Java 1.6 in –server mode is a little more than twice as fast as Ruby 1.9.

    I also have measurements using the “–fast’ option with JRuby that give better results but the use of this option is still experimental.

  57. roger said,

    February 14, 2009 @ 7:43 pm

    all right if I include the ruby version in the ruby benchmark suite?

    I think my one response to this is “please don’t take this as an indication that rails is fast–that is NOT to be inferred from these results.”
    Glad to hear from one commentor that RoR is second only to Django to them.
    Cheers!
    -=r

  58. Hongli Lai said,

    February 14, 2009 @ 9:34 pm

    Sure, go ahead.

  59. 50 Extremely Useful PHP Tools - المجموعة التقنية PSD Groups said,

    April 6, 2009 @ 7:32 am

    [...] PHP isn’t quick, but it is the most used scripting language in practice; it has detailed documentation, a huge [...]

  60. someone said,

    April 30, 2009 @ 4:21 pm

    according to http://www.php.net/manual/en/language.types.array.php PHP’s array is not an usual array. It is an ordered map. If you need to test fairly, you shouldn’t use the built-in PHP array.

  61. Meow said,

    May 18, 2009 @ 10:47 pm

    Really now….

    Reality is what language to use is often dependant on what one is trying to do. For example, if one is creating client server app’s meant to work across large a windows environment then ASP.NET, IIs, and Microsoft are usually your best choice (though Adobe is working towards this as well).

    PHP is “Messy” but its popularity has spawned slews of documentation, frameworks and more. Its not compiled, that sux. But, one can create compiled extensions… so thats good… sorta.

    Ruby, Python on and on and on… Point being… There is no specific standard to suit “all forms” of applications. PHP for enterprise distributed applications is a nightmare, yet Java handles such things albeit not painless like. If one is making a social networking application thats going to deal with several thousands of participants PHP can do the trick. But, if one is making Facebook where there are going to be millions, PHP is dead on arrival.

    Now to me whats most amazing is essentially C++ and Java are the speed demons in overall performance, scalability and then some. Java has a great deal of support, frameworks etc. But, C++ does not yet is older and more established in “general programming” than all others. That’s weird.

    I’d seem to me as the “fastest” run time environment, in fact, fast enough to be what PHP and countless other web apps even Apache HTTP Server… C++.

    With that said one would think that there would be OODLES of native C++ Web frameworks out there and the rest could go home. Granted, C++ one need deal with perhaps a bit more in the way of hassles but I am sure nothing that could not be overcome by the myraids of web coders out there.

  62. Hans said,

    June 28, 2009 @ 2:30 pm

    “But, if one is making Facebook where there are going to be millions, PHP is dead on arrival.”
    and still Facebook is built using PHP…

    Personally I like PHP and if you write your coded right then it is fast enough.

  63. Is Ruby being blamed for nothing? « Pacoup.com said,

    July 3, 2009 @ 2:55 pm

    [...] together in a neat package, but they tend to slow your application a bit. Basing ourselves on Hongli Lai’s blog post, it’s quite obvious that Ruby apps using Ruby previous to version 1.9 would be slower than [...]

  64. Luis José said,

    July 16, 2009 @ 12:54 am

    Hans, well, twitter is written in RoR so…

  65. Rodrigo said,

    July 27, 2009 @ 10:42 pm

    Could you update this and use Python 3.0.1 and JPython??

  66. Rodrigo said,

    July 27, 2009 @ 10:51 pm

    Jython*!

  67. Hans said,

    August 11, 2009 @ 9:39 am

    @Luis Jose

    >>”Hans, well, twitter is written in RoR so…”

    Essential parts of Twitter is again written in Scala. (Threading issues).

    CodeIgniter and C++API for Threading could have handled Twitter with ease.
    (This combo can Kick assss of all language frameworks out there)

    Not putting you down. Ruby is a gr8 language but there is still 2 years time to mature in terms of :

    1) consistency – I still read people’s problems installing Ruby in Windows XP box.
    2) speed – Ruby 1.9 speed is not enuf for me. I need it to be close to Java.
    3) libraries – Worst part !!! Still there are no free charting libraries in Ruby (Graphviz suckss assss),
    Wx-Ruby and Fx-Ruby are half-baked
    Sci/Math modules – where are they hiding? Can I do PCA analysis using Ruby?
    ChemRuby – lot of bugs in it.

    4)Others – Till Ruby fights java, there is no victory to it. Twitter people put Ruby down and Scala up.
    Compatibility – Still I can’t use Ruby 1.9 on RoR
    I need a browser plug-in like JRE plug-in for my apps.
    Without using JRuby, I need a pure ruby solution for my tasks.
    Cheers,
    Hans

  68. Amit Verma said,

    August 21, 2009 @ 7:22 am

    If you write something in a loop in PHP like –
    count($a) > 0

    And if PHP is trying to evaluate the size of array using count() function than PHP is doing it RIGHT.

    PHP needs to do what is “asked to do” and that is perfectly legitimate.

    There may be a chance that the size of the array is changing/modifying due to some operation inside the loop? In that case, if PHP is minding it’s business than that’s perfectly alright. If you’re sane enough you’ll write it this way -

    $arrSize = count($a);
    $arrSize > 0

    {Pretty Easy, Hunh??}

    Hope I made my point clear??


    Amit Verma

  69. 悠閒莊園 » Blog Archive » Scripting language 之選擇 said,

    October 10, 2009 @ 9:50 pm

    [...] 今天在這個赖洪礼的 blog – Ruby vs PHP performance中找到點跟據… 然而,我個人對 python,ruby 等都不很熟 ruby 更是沒做過有用的東西出來… 而且我自已在測試 ruby 1.8 時速度也沒很快,跟 php 差不多… Gentoo 也沒 ruby 1.9 所以現階段應不會多嘗試…但仍值得參考… [...]

  70. retry said,

    November 4, 2009 @ 8:28 am

    I ran your code on my dev box a deb 5.0.3 (lenny) set up with stock php/ruby packages

    $ php -v
    PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 26 2009 22:16:23)
    $ ruby -v
    ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]

    $ time ./mergesort.php

    real 0m6.303s
    user 0m6.200s
    sys 0m0.032s
    $ time ./mergesort.rb

    real 0m8.043s
    user 0m7.752s
    sys 0m0.292s

    But this one simple test is hardly enough to evaluate an entire language. These guys have been benchmarking languages for years:
    http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=ruby&box=1

    php is generally faster, although ruby 1.9 does better. Jruby doesn’t impress me at all.

  71. Exit said,

    January 9, 2010 @ 10:13 am

    Anyone run tests with compiled PHP (Zend encoded for instance)?

    That also should be considered.

  72. Robert K said,

    November 23, 2010 @ 11:18 pm

    Javascript version for testing Node.js (V8 interpreter):

    http://pastie.org/1321310

    Takes 0.26 seconds on my system (.vs. 4.6 seconds for ruby 1.8.7)

  73. 50个非常有用的PHP工具 | haohtml's blog said,

    December 20, 2010 @ 2:43 am

    [...] PHP是使用最为广泛的开源服务器端脚本语言之一,当然PHP并不是速度最快的,但它却是最常用的脚本语言。这里有50个有益的PHP工具,可以大大提高你的编程工作: [...]

  74. 50 个非常有用的PHP工具(转) - 王超 - 博客 BLOG said,

    March 9, 2011 @ 4:28 am

    [...] PHP是使用最为广泛的开源服务器端脚本语言之一,当然PHP并不是速度最快的,但它却是最常用的脚本语言。这里有50个有益的PHP工具,可以大大提高你的编程工作: [...]

  75. Why PHP? When do we need PHP? PHP vs Java vs Ruby vs ASP……. « Sujai SD said,

    March 26, 2011 @ 4:51 am

    [...] means anything without numbers…Some Performance test gives very less score for PHP – Is PHP slower than Ruby? Another one here But the way language works and the bench marks done may not be the right way of [...]

  76. dean said,

    July 14, 2011 @ 5:20 pm

    Ruby is marginally faster than PHP until you do anything with the database. If you’re using Rails forget about performance.

    Of course I’ve seen many, many other benchmarks of Ruby 1.9 and 1.91 that show it as significantly slower than 1.8.6 too, so I’m not sure if this is even legit or not.

  77. PHP开发工具。 | suliuer said,

    August 8, 2011 @ 7:28 pm

    [...] PHP是使用最为广泛的开源服务器端脚本语言之一,当然PHP并 不是速度最快 的,但它却是 最常用的脚本语言 。这里有50个有益的PHP工具,可以大大提高你的编程工作: [...]

  78. PHP开发工具大全(经典呀!不看后悔呀!) - WEB开发笔记 said,

    August 30, 2011 @ 3:30 pm

    [...] PHP是使用最为广泛的开源服务器端脚本语言之一,当然PHP并不是速度最快的,但它却是最常用的脚本语言。这里有50个有益的PHP工具,可以大大提高你的编程工作: [...]

  79. 50个非常有用的PHP工具 | 林洪优的博博 said,

    July 16, 2013 @ 6:16 am

    [...] PHP是使用最为广泛的开源服务器端脚本语言之一,当然PHP并不是速度最快的,但它却是最常用的脚本语言。这里有50个有益的PHP工具,可以大大提高你的编程工作: [...]

  80. Monitor Infantil said,

    July 20, 2014 @ 5:10 pm

    Have you ever considered about including a little bit
    more than just your articles? I mean, what you say is fundamental and all.
    Nevertheless imagine if you added some great images or videos
    to give your posts more, “pop”! Your content is excellent but
    with pics and videos, this blog could undeniably be one of the most beneficial
    in its niche. Very good blog!

RSS feed for comments on this post · TrackBack URI

Leave a Comment