Ruby vs PHP performance
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. 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:
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 7.10
- Hardware: Intel Core 2 Duo T5300 1.73 Ghz, 2 GB RAM
- Versions: PHP 5.2.3-1ubuntu6.2, Ruby 1.8.6 (2007-06-07 patchlevel 36), Perl 5.8.8, Python 2.5.1
- 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.1, 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 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.
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.
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.
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 […]
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.
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.
DieLaughing said,
January 17, 2008 @ 10:47 pm
Yeah, it’ll mergesort, but does it blend?
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.
Hongli said,
January 17, 2008 @ 11:22 pm
RayNBow said:
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).
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.
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 ]
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
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);
ara said,
January 18, 2008 @ 5:58 am
wow! trully Ruby is faster than PHP.
thanks for the info.
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.
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.
「2007年に一番伸びた言語はPython」とスクリプト言語の速度比較 | テクトリム said,
January 18, 2008 @ 11:25 am
[…] via ZDNet Japan via Elliott C. Back via 赖洪礼的 blogC++ java perl php python ruby software スクリプト言語 ニュース 速度比較 […]
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)
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 […]
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?
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.
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.
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.
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 […]
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.)
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…
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 […]
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)…
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…
retry said,
January 26, 2008 @ 4:02 am
I’m tired of rubyfag lies…
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. […]
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 […]
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 […]
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.
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.
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.
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 […]
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
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
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…
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
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..]
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++. […]
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.
Hongli said,
April 29, 2008 @ 10:23 pm
Xeno, the test *was* run from the CLI…
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.
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).