Elliott C. Back: Internet & Technology

Ruby vs PHP Performance Revisited

Posted in Code,Performance,Scalability,Web 2.0 by Elliott Back on January 17th, 2008.

Ignoring any of Hongli Lai’s actual code, I reran the PHP, Ruby, C++, Perl, and Python mergesort benchmarks he gave, and came up with substantially different results. Here are the versions of the programming languages I am using for the test:

  • PHP – PHP 5.1.6 (cli) (built: Sep 18 2007 09:07:28)
  • Ruby – ruby 1.8.5 (2007-09-24 patchlevel 114) [x86_64-linux]
  • Perl – This is perl, v5.8.8 built for x86_64-linux-thread-multi
  • Python – Python 2.4.4 (#1, Oct 23 2006, 13:58:18)
  • C++ – gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
  • Java – Java(TM) SE Runtime Environment (build 1.6.0_10-ea-b10)

You’ll notice I’m adding Java into the mix for fun. Here’s the results, over 10 runs, on an Intel Dual-core 1.80GHz machines with 2Gb of RAM currently running this website:

mergesort-performance.png

Lang	Average	Min	Max
PHP	8.8325	8.637	9.303
Ruby	7.2896	7.143	7.729
Perl	4.3231	4.262	4.428
Python	3.3465	3.289	3.417
C++	0.5638	0.53	0.609
Java	0.4062	0.262	0.551

There are a couple important conclusions to note here that are significantly different than Hongli Lai’s:

  • PHP is 21% slower than Ruby, not 41% as in his benchmark
  • Python is 29% faster than Perl, not 17% as in his benchmark
  • Java runs this 39% faster than C++, and 2100% faster than PHP

So, PHP is slower than Ruby, but not quite as slow as Hongli Lai would have you believe. Python is the fastest scripting language in this benchmark, while Java is the faster language all around, and is incredibly, incredibly fast. Maybe all of our code should start using java!

* NOTE: I am ignoring the obvious deficiencies of this micro-benchmark and just trying to reduplicate it. What I’ve found is that there are significant discrepancies between Hongli Lai’s run of the tests and my own, probably owing to slightly different versions of the components involved. Also, if I make some trivial optimizations to the loops in the PHP script, I can get it to run faster than everything but C++, in about 2.4s. Then again, just calling sort() is faster by another two orders… but still half as slow as Java’s built-in sort… and two orders slower than perl’s built-in.

Facebook’s Next Trick: Different Information for Different Networks

Posted in Facebook by Elliott Back on September 7th, 2007.

So we all know that Facebook is going to let search engines start indexing parts of its member profiles so that it can cash in on vanity name traffic. This is all well and good, but one way Facebook could turn this from a PR prank into a serious feature would be allowing customization of your own profile by Network. That’s right–I want to show Search Engine visitors one thing, my friends another thing, my friends’ friends another, and something special for strangers and the people in my network.

So my friends would get to see this:

friends.jpg

But I don’t want search engine visitors to see more than this:

weirdos.jpg

You can, to some degree, use Facebook’s privacy controls to restrict information, but that’s slightly different than controlling its flow. New controls would let you seperate, for example, your friends and your girlfriend’s friends, or your personal life and professional profile. Facebook, put an end to “banking applicant has facebook profile of keg chugging,” please!

Facebook Platform Instability

Posted in Errors,Facebook,Scalability,Web 2.0 by Elliott Back on June 30th, 2007.

Of the last 40 updates I’ve made to my Facebook Application for showing Stock Quotes, 6 have failed with a “Unknown data store API error.” While I have no idea what the error means, it seems to indicate that Facebook couldn’t save the data I sent it at a 15% rate for that period of 10 hours.

alexa.png

Other Facebook Platform issues include restricted growth, bugs in the developer application, downtime, and poor performance. Obviously, F8 will go through some growing pains before it fully matures.

Next Page »