
Box's HHVM Migration - tomkwok
https://code.facebook.com/posts/1607907626123431/under-the-hood-box-s-hhvm-migration/
======
joesmo
Nice. The 2-3x improvement is about the same that I've seen in preliminary
tests with HHVM on a JSON API in ZF2. There are still many extensions that are
not ported at all, something Box didn't run into but I have. These are lesser
known extensions, but they can throw a wrench in the migration works. I would
definitely check the status of all extensions and as the article mentions,
test their code most extensively.

My biggest problem still is getting xDebug working with HHVM, something that
after a few days of trying I have given up on once again (as of a couple of
months ago). Unfortunately, a procedural or OOP language without a proper
debugger (hphpd doesn't count) is pretty useless for real-word development. I
know the HHVM team is constantly working on improving the ecosystem, so
hopefully at some point, we'll have a real debugger that runs without
crashing. Once that happens, I can definitely see rewriting the sections of
the app that use extensions not yet ported to get the app ready for deployment
on HHVM. Right now, the only reason we haven't done so is that we do want to
compare both HHVM and PHP7 to see which one will yield the best performance.

------
VeejayRampay
I wish Twitter had pulled a HHVM with Ruby on Rails. I really do cause HHVM's
benefits for PHP-based code bases looks appealing.

~~~
ciupicri
Hasn't Twitter switched to Scala?

~~~
VeejayRampay
They have for at least parts of their infrastructure but there was a time
where they were heavily invested in Ruby on Rails just like Facebook and PHP.
They could have chosen to work on the framework and Ruby itself to make things
better, they chose to move on to greener pastures instead. As a Ruby developer
I regret that didn't "pull a HHVM", would have made my life easier, just HHVM
and the whole FB/HHVM/Hack ecosystem is making PHP devs' life easier.

~~~
chrisseaton
Are you just after a faster Ruby? We're working on an implementation of Ruby
that is often an order of magnitude faster than anything else out there
[http://www.chrisseaton.com/rubytruffle/](http://www.chrisseaton.com/rubytruffle/).

Or is it the typing and other infrastructure you wanted?

~~~
VeejayRampay
In the general sense I am absolutely after a faster Ruby. I am also after a
Ruby with better tooling, better error handling and all bells and whistles.
I'm following your development on Ruby Truffle with a lot of excitement, but
like most Ruby / Ruby on Rails developers, the only thing that I wish is that
I can just switch the Ruby and have it work exactly the same, except
faster/better/stronger.

From what I understand JRuby/Truffle is closing the gaps at a nice pace (your
recent tweets on constant folding is even showing that you're aiming not only
for feature parity but for feature parity AND MOAR and that's awesome), but
with existing applications and associated gems and all the implication of
having to switch my Ruby to another slightly more exotic one, the thought is
currently a source of anguish (because a lot of the existing ecosystem is
extremely tied and tailored to MRI for better of for worse). I'm simply
waiting for the time where I can just replace a line in my Gemfile and reap
the benefits.

That being said, I would like to thank you for all the efforts you're putting
in this, the blog entries, the Ruby Bibliography and all its promising
research on making the Ruby ecosystem better, the benchmarks and overall
collaboration with the folks at JRuby and I hope we get to see lots of good
things in the future from your end.

~~~
chrisseaton
Yeah we're going for being indistinguishable from MRI (unless you want to use
the extra features). We even have a simple statically linked build that does
not require a JVM, so that you're just running a simple binary like in MRI.
That coupled with our support for MRI's C extensions is our strategy for MRI
compatibility.

------
geerlingguy
FYI, PHP 7 (which is in beta status) is close to HHVM now, speed-wise (using
Drupal, Wordpress, Symfony, etc.)[1][2], and it also includes many of the
features HHVM + Hack added onto PHP in the first place.

Not 1:1 feature parity, of course, but a lot of people who were
testing/considering a move to HHVM/Hack have reconsidered now that PHP 7 fixes
many of the language's pain points.

Competition is good!

[1] [http://kazanir.github.io/profiling/](http://kazanir.github.io/profiling/)

[2] [http://hhvm.com/blog/9293/lockdown-results-and-hhvm-
performa...](http://hhvm.com/blog/9293/lockdown-results-and-hhvm-performance)

------
elktea
Interesting you're considering Hack. Does Hack fix all the weird warts PHP has
carried into this century?

~~~
alexbilbie
Some of Hack's features such as return type declarations and scalar type hints
will be in PHP 7 due to be released later this year.

PHP 7 also includes some serious performance improvements, contextual parsing,
anonymous classes, combined comparison operator, null coalese operator and
tens of other new features.

~~~
ihsw
Indeed.

Also, preliminary reports indicate that PHP7 is near parity in speed/memory
usage with HHVM (and in some cases exceeding it).

