Nick Bastin

Slashdot simply reposted this blog entry at:

http://developers.slashdot.org/story/09/12/20/1433257/The-Environmental-Impact-of-PHP-Compared-To-C-On-Facebook

Passing on an opportunity to bash slashdot for lacking any sort of edited treatment of these stories (if they advertised themselves as a curated RSS aggregator, I wouldn’t even care about this, but they don’t), the source entry itself is not much short of a marketing pitch. It’s written by the people who write (and sell) a C++ web toolkit known as wt (memories of reviews written by game publishers, anyone?).

They obviously have an agenda, and they get a bit overzealous in their pitch. The fastest C++ is almost certainly faster than the fastest PHP – you probably won’t find anyone who would argue with that. However, they make a couple of rather outlandish claims:

• “assuming a conservative ratio of 10 for the efficiency of C++ versus PHP code” – using a general computing benchmark which contains no code that spends any time doing things you’d find on the web.
• “As they only say that “the bulk” is running PHP, let’s assume this to be 25 000 of the 30 000.” – Even if 25000 servers are in fact running PHP, it’s ridiculous to assume that 100% of their CPUs are consumed running PHP scripts. One would hope, certainly, that while PHP is used to generate dynamic data, that a lot of that data can be forward-cached and served again.

Certainly without more detailed data from Facebook, all of this is speculation at best. We have no idea what the mix of objects served by Facebook is between static/dynamic/cached. I have no doubt that if you started a reasonable cap and trade system for emissions, data centers might start caring a lot more about how efficient their code is, and this is a discussion that needs to be had. However, it needs to be had responsibly, bounded by the data we have, and not filled with conjecture created merely to sell a competing product.