Facebook speeds up PHP | Hacker News Reader

Facebook speeds up PHP

readwriteweb.com

81 pointsmcxx25 comments

"We wish Facebook had made this project open, as we're sure many PHP developers would concur that the efforts would have been much swifter and more beneficial to the public had more folks and a larger team been involved from the outset."

Considering the uproar generated by introducing something like namespaces into PHP, I strongly suspect the opposite of the bit in italics to be true. In fact, that's possibly why they did it this way.

This is pure crap. phc (http://www.phpcompiler.org) has been open source for 4 years and actively soliciting help for 2 years. Did anyone in the PHP community step up to help? Not one.

(I mean the quote is pure crap, not your comment).

Though you never know what effect having Facebook's name attached to the program would have done for its acceptance into the ranks of PHP programmers. Would you rather help Facebook do something or phpcompiler.org do something...

Exactly. Have a look through the IRC logs from when the core devs were discussing namespace separators, and let's see if the author of this quote still feels the same way.

The PHP internal community is disfunctional. If I were Facebook, I'd do an much as possible without it.

It might make more sense to wait the supposed few hours and see what Facebook actually releases. Especially if one is going to berate them for not releasing (as open-source) something before they've released anything.

They are wrong to say that Unladen Swallow gets a 5x speedup. That was their initial plan, but they claim now they were naive. Their speedup in less than 2x.

I think this reporting is a little haphazard.

unladen-swallow does not get a 5x speedup, but pypy gets pretty close.

http://morepypy.blogspot.com/search?updated-min=2010-01-01T0...

http://article.gmane.org/gmane.comp.lang.lua.general/42210 is tangentially related.

Being slower on a third out of 15 benchmarks is not actually 'pretty close'. Pypy results are impressive given the task at hand and approach taken. But it's not anything like 5 times faster or close, by any measure.

I agree with Mike Pall's view. And the current crop of Javascript engines proves that too. Simplicity wins over complexity.

Although I still hope pypy will deliver on its promisses. We have to bear in mind that pypy's goal is not just enhanced speed. Its goals are much broader and this is one reason why, perhaps, this is not the best approach if you want full speed (there are trade offs which seem acceptable considering all the other benefits, such as easier of implementation of dynamic languages on top of pypy's framework).

There's so much disinformation in those comments. One person is happy that they are moving to php (what?), another person now has a good reason to say that php is faster than other languages. That's hilarious

Just came here to say the same thing. Also loved many saying that Facebook hasn't open sourced anything (and even in the ones that do realize that they've open sourced code, no one mentions Tornado).

"...that will increase speed by around 80%..."

I guess this is compared to plain PHP not to accelerators? And what exactly is the difference from a PHP accelerator?

The typical PHP accelerators cache bytecode rather than native code.

Yes but I wonder how much it will really help. Is the bottleneck for Facebook-like sites really in the bytecode dispatching as opposed to e.g. string/regexp operations or database calls?

Could be, in the case that those two have already been optimized or removed as much as possible.

It seems sensible to assume it helps them for something otherwise why bother developing and releasing it? I also don't think it's a matter of bottleneck - if you make the front-end php run faster you need fewer servers, fewer servers/user, more money. This has come up in discussions about google as well - there are some scales at which even comparatively modest improvements in efficiency count. It probably won't make a world of difference to My Cousin's Personal Basement URL Shortener.

>It seems sensible to assume it helps them for something otherwise why bother developing and releasing it?

Well surely the proof is in the eating - that is, if they've implemented it then it clearly works, they wouldn't be stupid enough to implement it if it's going to cost them money.

To answer your [rhetorical] question: The cost for this has been one developer for a year. That's not much for a speculative shot at increased server efficiencies that could save them big money in the server farm. Once they've developed it, even if it didn't produce the gains they needed then releasing it is sensible as it gains them some PR amongst the OS community and may get more fixes from that same community improving the result (lower costs) for FB.

We don't really know anything about it. One developer, five developers, 10, 20, 9923123% better. Let's just see what they release, if anything.

Sorry I read somewhere else that it was a single dev and that the gains were expected to be 5x improvement in speed for the same processing power. Can't recall where.

JIT native code compilers do make quite a bit of difference over byte code execution is some situations. E.g. loops over many elements (say loops that concatenate large HTML fragments, ok the string operation are already native, but other bits of the loop will not be (e.g. array access)).

So, I agree that the main 'bottleneck' in most PHP apps is probably not-PHP itself, there is still scope for improvement.

As far as I can tell Facebook use memcached so extensively that practically everything is served out of it, so their bottleneck could well be the PHP application code as opposed to the data fetching. In any case, when you're serving potentially millions of page views a second even a small optimisation can save you from buying a ton of extra hardware.

When you're running 1000s of servers, it's not about the one big bottleneck anymore. 5 or 10 or 20% improvements then suddenly become worthwhile.

I think it is quite irrelevant to wonder about such details, as the article proceeds to spout nonsense like

   The project is very similar to Google's Unladen Swallow
   project, which rebuilt the Python compiler, boosting the
   speed fivefold [..]

There is not a word to be trusted, as the author clearly doesn't know what he is talking about.

Did they release any kind of benchmarks? I'm curious how this stacks up to passenger and Ruby enterprise edition (faster i'm sure), but would be interesting to see a side by side comparison.

Reply on news.ycombinator.com