“Facebook开发的高性能PHP虚拟机HHVM比官方的PHP解释器快超过9倍”的说法是否属实？

HHVM (aka the HipHop Virtual Machine) is an open-source virtual machine designed for executing programs written in Hack and PHP. HHVM uses a just-in-time compilation approach to achieve superior performance while maintaining the flexibility that PHP developers are accustomed to. To date, HHVM (and its predecessor HPHPc before it) has realized over a 9x increase in web request throughput and over a 5x reduction in memory consumption for Facebook compared with the PHP 5.2 engine + APC.
注：HHVM支持PHP和Hack两种语言的解释编译。
Hack是FB搞的、一门更像C语言的PHP分支，添加了类型支持，语法上大致就从

$i = 1;

回复内容：

PHP5.2时代，这样的测评结果是有可能的，这是PHP5.3依赖，PHP核心团队把性能改善拍排在很前面的原因。

HHVM快是因为JIT，能在运行时先动态优化再编译执行：

1.

比如

// 定义两个function
function foo() {}
function bar() {}
// 调用只用到foo()，没用到bar()
foo()

争论这个完全 没有意义~ 这就好比争论公鸡和母鸡谁更能下单 ~ 除非你有机会能进程亿级这个量级 才能有机会接触这个。。 如果真到那个时候 你已经超越码农存在 也不会在知乎上。 SO
要有时间还是关注下 前言技术 了解语言本身的基础 ~~ 类型的动态绑定改成了静态绑定啊。
类型的动态绑定用的是爽，但是代价不小。
代价1：类型检查要在运行时进行。
代价2：变量值的空间要可变，不同的类型需要的存储空间是不同的。
代价3：处理动态绑定一般要解释器来做。解释器比编译器慢多少不用说了吧。

所以咯，如果能够去掉上面的几个代价，提速和节约内存是当然的。 既然你都知道int $1 = 1;就是int i=1;了，你觉得既然C语言比PHP快那么多，为什么HHVM就不行呢？ 其实聊HHVM的根本原因还是对PHP的优化

• 大家对于这一类“动态语言”比较常见的优化是，在性能瓶颈的地方用其他语言（代表性的C/C++）来代替，比如Twitter就将大量的业务逻辑放到了Scala里，而Rails只负责前端页面上的展现。
  
• 另外一种比较高级的方案是优化官方语言的实现，比如Zend，如果分析过PHP的代码，就会发现它的C代码除去空行注释后居然还有80+万行（PHP 5.2.1），而Zend引擎部分只有不到10万行。
• 比第一个方法更进一步的是，将PHP代码转成C/C++，然后编译成本地代码；
  
• 上面的效果很显著，但是缺点也很明显，就是开销很大！WORE，那就来试着做一个更好的实现虚拟机；

从HHVM的发展轨迹上看，很类似于：
HPHPc------>HPHP（08年开始Facebook就开始使用的HipHop，包括HPHPc、HPHPi、HPHPd）----->HHVM（维基百科：HHVM是在HPHPc的基础上构建，它会将PHP代码转换成高级别的字节码，在运行时即时JIT编译器会将这些字节码翻译成机器码。）

而HHVM快的原因，在各种新闻报道中都提到了bytecode+JIT这个关键技术，其实研究JIT的路子也走了很长。
比如：

2010 年 IBM 日本研究院基于他们的JVM代码开发了P9，性能是官方PHP的2.5到9.5倍，论文Evaluation of a just-in-time compiler retrofitted for PHP；
2008 年有人用 LLVM 实验过zend虚拟机，结果是慢了 21 倍——llvm.org 的页面；

而且JIT本身也是会耗时的，对于一些很简单的程序，执行过程上优化不完全，没准还比interpreter慢，比如JAVA和.NET最初版本的JIT在性能测试时很容易就被干掉，所以并不存在绝对的事情，更多还是在细节问题的处理上（参考HHVM的发布轨迹），其中最关键的上面的兄弟已经说到了，就是类型的推断已经从语言转移到了程序员身上，HHVM编译出来的代码直接使用了原生类型，避免了interpreter对参数的判断和box、unbox的问题，正是这一点明显提升了性能，甚至做到了和C语言的执行效果不大。

目前HHVM还是存在一些问题，比如对第三方扩展支持较少（比如MongoDB、Redis，在底层还是要用PHP代码实现）、内存泄露问题等等，但长远来看，除非PHP被其他替代掉，否则算是一个趋势。 没有得到社区的支持，PHP7才是未来，hhvm只会昙花一现 去一家公司面试时问过hhvm当时没了解过 直接回答问题，并不属实。（或是在特定环境下得出的偶然结论）

实测多种市场流行cms framework的benchmark，在大多数情况下同等环境的性能优劣是php7 > hhvm > php5。并且性能差距还没遇到过大于100%的情况。

值得一提的是，在php5直接转换到hhvm的情况下，有些cms的第三方模块会产生兼容性问题。