Miniscule improvements are worth large amounts of money at Facebook's scale. They have an excellent team of C++ and compiler developers working on HHVM, and they see no reason to waste time attempting something in PHP when they could make it run faster in native code without much more initial effort (and probably less effort over time).

I would hope that their JIT'ing VM could come close to native performance (and rarely faster as tracing JITs can occasionally be). It's about drawing the line somewhere. It's like choosing between Phalcon and Symfony. I understand their internal needs at Facebook, but considering the effort they are putting in to make non-Facebook codebases work I don't think it's too much of a stretch to implement some of the runtime in PHP.

Whenever we can, we build extensions in PHP https://github.com/facebook/hhvm/tree/master/hphp/system/php

Many of the older extensions that were imported back in the HPHPc days are in C since they were much easier to port from php-src if we didn't have to translate the language.

As for why this was't in PHP, two reasons. It was easier to stay in the language since our event loop code was already in C++, and most of the gains we get from writing library code in PHP comes from not having to cross a language barrier from userland code. The event loop is not the best place for that.

because PHP is "slow" and c is "fast", just about anything thats written in PHP such as FastCGI parser would be daftly slow compared to a counterpart written in c or c++. Most people will not be prepared to sacrifice perfomance just for the sake having everything in PHP