I 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 to test the speed at which they ran. I found it interesting that this particular merge script written in Ruby took only 3/4 of the a time to run. So I downloaded his exact scripts that he used and tested on one of my server machines. The only one I didn’t run was the C++ version of this merge sort.
I suppose I could do a graph like Izumi over at that blog, but I don’t have Office installed on this computer to make a quick graph. If you visit that post, near the bottom will be the sources for all of the scripts that I used. I suppose I could have written my own, but I thought it would be much quicker if I used the same scripts that he used just to be consistent. To time these scripts, I used the linux command time and here are the direct results:
PHP
real 0m7.329s
user 0m7.299s
sys 0m0.008s
real 0m7.299s
user 0m7.290s
sys 0m0.004s
real 0m7.274s
user 0m7.269s
sys 0m0.006s
Ruby
real 0m7.683s
user 0m7.682s
sys 0m0.001s
real 0m7.497s
user 0m7.472s
sys 0m0.021s
real 0m7.485s
user 0m7.442s
sys 0m0.019s
Perl
real 0m4.595s
user 0m4.578s
sys 0m0.003s
real 0m4.627s
user 0m4.608s
sys 0m0.003s
real 0m4.634s
user 0m4.623s
sys 0m0.004s
Python
real 0m3.573s
user 0m3.566s
sys 0m0.002s
real 0m3.539s
user 0m3.537s
sys 0m0.002s
real 0m3.602s
user 0m3.598s
sys 0m0.005s
On my system, which has 4GB of ram, quad core processor, it’s showing that the PHP script runs slightly faster than the Ruby script. This is a big difference from the results of that on izumi’s blog, I wonder why. Python and Perl results were similar in that it’s faster. Maybe PHP works better in environments with a lot of RAM? Does anyone know why there’s a big difference between my results and izumi’s results? I would love to know the reason.
Serpantin · October 16, 2008 at 8:20 am
Well done! I knew Ruby couldn’t be faster than PHP, they are both high-level interpreters FGS!
Thank you for the test. Thank you big time!
Admin comment by A.K. · October 16, 2008 at 9:38 am
Why thank you
PHP Faster than Python? · December 5, 2008 at 5:57 pm
[...] PHP, Python runs slower?" It intrigued me since I already did something similar to this before here. It has been said that Python is faster than PHP, but why in this case, Python is clearly slower [...]
Trejkaz · August 20, 2009 at 5:22 am
Erm, Serpentin… that was the old VM. Presumably the new one is still radically faster (as JRuby should also be.) So really what makes the tests on this page convenient is that it uses the *slowest* Ruby implementation available.
Of course this is even more so the case almost a year later, as JRuby has made even more leaps since then…
Tom · December 7, 2009 at 3:18 pm
People just like to take sides and make false or unfounded claims. I’ve heard so many times this is better or that is better. I’ve then went off and looked for benchmarks because generally the person telling me what was better couldn’t prove anything. They just said it was better and that was that. Like whatever they said was true. Well, if I quack like a duck I’m not going to sprout wings and fly. So…
I saw that the original tester there updated his test. Did he skew the numbers not to look wrong and prove himself wrong? Who knows. I’ll take +/- half a second or so as just normal variation. If you keep running the tests you’ll get different rules. Was there any other processes running on the computer? Did something else spike because it had to perform some kinda check on something in the system? I mean it’s so hard to ever test. However the jump in those test results where all of a sudden a newer version of Ruby is faster than Python…..?? Uh. caubullshcaught bullshcaugh …excuse me. Yea, well it makes perfect sense Python is faster and then you have C++. But I mean he might as well put the numbers as Ruby being faster than C++.
However. Half a second running a sort operation or even 4 seconds running it is of no consequence. What the original tester did point out (which is great that he did) was that who knows when it comes to the application of the language. Ruby on Rails is a great framework but if it slows things down…It slows things down. Now take PHP and it’s frameworks. Say CakePHP which aims to mirror RoR (mostly). Which is faster? At what? Doing what? Real world…Say a blog? Well it depends. Do you know that you can code a “blog” to do the same thing all of a couple thousand different ways using both frameworks??
So testing is a little silly because in the real world you have so many other factors. Plus none of these tests were under any HTTP load. So who knows how they interface and work with Apache. I mean that right there could make the difference. On top of user code.
The one thing I want to point out is the false assumption that none of these languages scale. NO. They ALL scale. Scaling is not defined by how fast a language can run through a loop and sort something. Scaling is done by means of being able to expand your infrastructure to handle the load (in this case web user traffic). If you can code a RoR or CakePHP app to use multiple databases and live in a load balanced Apache environment (and you can, both frameworks are designed for this…and with ease) then you CAN scale. It doesn’t really matter if one language can execute a sort faster or not. Your web app isn’t sorting and if fractions of a second all equate to you needing 50 or 51 servers to handle the traffic….When traffic itself fluctuates and even grows so you’d only need more servers one day anyway….Honestly, who cares? At the point where you’re talking about needing an additional server or two or fifty when you have dozens of them already…You better sure as hell have some kinda revenue paying for all those servers at that point. I don’t think using one language over another is ever going to be proved to equate to thousands of dollars in savings. If so. Where are those benchmarks?
Admin comment by A.K. · December 9, 2009 at 12:46 pm
Tom,
Quite an interesting yet informative rant. I agree with you that benchmarks do depend on a lot of factors, but statistically speaking, if you run it enough times, you should be able to have conclusive evidence that one is faster than another.
Of course, in real life, it doesn’t matter the number of milliseconds of improvements. One can always scale up or scale out, just depends on what you want to do. However, on the other hand, processor intensive applications (graphics, simulation, cad, etc…) do need the fastest languages (and easiest of those.) But I do agree with you, for the majority of webapps, the language you choose should be a personal one and not one based solely on benchmarks.