Howdy,
Most of the code in MediaWiki works just fine with it
(since most of
it is mundane) but things like dynamically including certain files,
declaring classes, eval() and so on are all out.
There're two types of includes in MediaWiki, ones I fixed for AutoLoader and ones I
didn't - HPHP has all classes loaded, so AutoLoader is redundant.
Generally, every include that just defines classes/functions is fine with HPHP, it is just
some of MediaWiki's startup logic (Setup/WebStart) that depends on files included in
certain order, so we have to make sure HipHop understands those includes.
There was some different behavior with file including - in Zend you can say
require("File.php"), and it will try current script's directory, but if you
do require("../File.php") - it will
We don't have any eval() at the moment, and actually there's a mode when eval()
works, people are just scared too much of it.
We had some double class definitions (depending on whether certain components are
available), as well as double function definitions ( ProfilerStub vs Profiler )
One of major problems is simply still not complete function set, that we'd need:
* session - though we could sure work around it by setting up our own Session abstraction,
team at facebook is already busy implementing full support
* xdiff, mhash - the only two calls to it are from DiffHistoryBlob - so getting the
feature to work is mandatory for production, not needed for testing :)
* tidy - have to call the binary now
function_exists() is somewhat crippled, as far as I understand, so I had to work around
certain issues there.
There're some other crippled functions, which we hit through the testing...
It is quite fun to hit all the various edge cases in PHP language (e.g. interfaces may
have constants) which are broken in hiphop.
Good thing is having developers carefully reading/looking at those. Some things are still
broken, some can be worked around in MediaWiki.
Some of crashes I hit are quite difficult to reproduce - it is easier to bypass that code
for now, and come up with good reproduction cases later.
Even if it wasn't hotspots like the parser could
still be compiled
with hiphop and turned into a PECL extension.
hiphop provides major boost for actual mediawiki initialization too - while Zend has to
reinitialize objects and data all the time, having all that in core process image is quite
efficient.
One other nice thing about hiphop is that the compiler
output is
relatively readable compared to most compilers. Meaning that if you
That especially helps with debugging :)
need to optimize some particular function it's
easy to take the
generated .cpp output and replace the generated code with something
more native to C++ that doesn't lose speed because it needs to
manipulate everything as a php object.
Well, that is not entirely true - if it manipulated everything as PHP object (zval), it
would be as slow and inefficient as PHP. The major cost benefit here is that it does
strict type inference, and falls back to Variant only when it cannot come up with decent
type.
And yes, one can find offending code that causes the expensive paths. I don't see
manual C++ code optimizations as way to go though - because they'd be overwritten by
next code build.
Anyway, there're lots of interesting problems after we get mediawiki working on it -
that is, how would we deploy it, how would we maintain it, etc.
Building on single box takes around 10 minutes, and the image has to be replaced by
shutting down old one and starting new one, not just overwriting the files.
Domas