PHP 性能优化

    php.net官网上给出了两点解释：

   

      回收可能根有细微的性能上影响，但这是把PHP 5.2与PHP 5.3比较时才有的。尽管在PHP 5.2中，记录可能根相对于完全不记录可能根要慢些，而PHP 5.3中对 PHP run-time 的其他修改减少了这个性能损失。

这里主要有两个领域对性能有影响。第一个是内存占用空间的节省，另一个是垃圾回收机制执行内存清理时的执行时间增加(run-time delay)。我们将研究这两个领域。

内存占用空间的节省 ¶

首先，实现垃圾回收机制的整个原因是为了，一旦先决条件满足，通过清理循环引用的变量来节省内存占用。在PHP执行中，一旦根缓冲区满了或者调用gc_collect_cycles() 函数时，就会执行垃圾回收。在下图中，显示了下面脚本分别在PHP 5.2 和 PHP 5.3环境下的内存占用情况，其中排除了脚本启动时PHP本身占用的基本内存。

Example #1 Memory usage example

<?php
class Foo
{
    public $var = '3.1415962654';
}

$baseMemory = memory_get_usage();

for ( $i = 0; $i <= 100000; $i++ )
{
    $a = new Foo;
    $a->self = $a;
    if ( $i % 500 === 0 )
    {
        echo sprintf( '%8d: ', $i ), memory_get_usage() - $baseMemory, "\n";
    }
}
?>

在这个很理论性的例子中，我们创建了一个对象，这个对象中的一个属性被设置为指回对象本身。在循环的下一个重复(iteration)中，当脚本中的变量被重新复制时，就会发生典型性的内存泄漏。在这个例子中，两个变量容器是泄漏的(对象容器和属性容器)，但是仅仅能找到一个可能根：就是被unset的那个变量。在10,000次重复后(也就产生总共10,000个可能根)，当根缓冲区满时，就执行垃圾回收机制，并且释放那些关联的可能根的内存。这从PHP 5.3的锯齿型内存占用图中很容易就能看到。每次执行完10,000次重复后，执行垃圾回收，并释放相关的重复使用的引用变量。在这个例子中由于泄漏的数据结构非常简单，所以垃圾回收机制本身不必做太多工作。从这个图表中，你能看到 PHP 5.3的最大内存占用大概是9 Mb，而PHP 5.2的内存占用一直增加。

执行时间增加(Run-Time Slowdowns) ¶

垃圾回收影响性能的第二个领域是它释放已泄漏的内存耗费的时间。为了看到这个耗时时多少，我们稍微改变了上面的脚本，有更多次数的重复并且删除了循环中的内存占用计算，第二个脚本代码如下：

Example #2 GC性能影响

<?php
class Foo
{
    public $var = '3.1415962654';
}

for ( $i = 0; $i <= 1000000; $i++ )
{
    $a = new Foo;
    $a->self = $a;
}

echo memory_get_peak_usage(), "\n";
?>

我们将运行这个脚本两次，一次通过配置zend.enable_gc 打开垃圾回收机制时，另一次是它关闭时。

Example #3 执行以上脚本

time php -dzend.enable_gc=0 -dmemory_limit=-1 -n example2.php
# and
time php -dzend.enable_gc=1 -dmemory_limit=-1 -n example2.php

在我的机器上，第一个命令持续执行时间大概为10.7秒，而第二个命令耗费11.4秒。时间上增加了7%。然而，执行这个脚本时内存占用的峰值降低了98%，从931Mb 降到 10Mb。这个基准不是很科学，或者并不能代表真实应用程序的数据，但是它的确显示了垃圾回收机制在内存占用方面的好处。好消息就是，对这个脚本而言，在执行中出现更多的循环引用变量时，内存节省的更多的情况下，每次时间增加的百分比都是7%。

PHP内部 GC 统计信息 ¶

在PHP内部，可以显示更多的关于垃圾回收机制如何运行的信息。但是要显示这些信息，你需要先重新编译PHP使benchmark和data-collecting code可用。你需要在按照你的意愿运行./configure前，把环境变量CFLAGS设置成-DGC_BENCH=1。下面的命令串就是做这个事：

Example #4 重新编译PHP以启用GC benchmarking

export CFLAGS=-DGC_BENCH=1
./config.nice
make clean
make

当你用新编译的PHP二进制文件来重新执行上面的例子代码，在PHP执行结束后，你将看到下面的信息：

Example #5 GC 统计数据

GC Statistics
-------------
Runs:               110
Collected:          2072204
Root buffer length: 0
Root buffer peak:   10000

      Possible            Remove from  Marked
        Root    Buffered     buffer     grey
      --------  --------  -----------  ------
ZVAL   7175487   1491291    1241690   3611871
ZOBJ  28506264   1527980     677581   1025731

主要的信息统计在第一个块。你能看到垃圾回收机制运行了110次，而且在这110次运行中，总共有超过两百万的内存分配被释放。只要垃圾回收机制运行了至少一次，根缓冲区峰值(Root buffer peak)总是10000.

结论 ¶

通常，PHP中的垃圾回收机制，仅仅在循环回收算法确实运行时会有时间消耗上的增加。但是在平常的(更小的)脚本中应根本就没有性能影响。

然而，在平常脚本中有循环回收机制运行的情况下，内存的节省将允许更多这种脚本同时运行在你的服务器上。因为总共使用的内存没达到上限。

这种好处在长时间运行脚本中尤其明显，诸如长时间的测试套件或者daemon脚本此类。同时，对通常比Web脚本运行时间长的» PHP-GTK应用程序，新的垃圾回收机制，应该会大大改变一直以来认为内存泄漏问题难以解决的看法。

接下来，看了一篇文章写的挺棒的，拿facebook举例，供大家参考，小弟确实学艺不深

HHVM 是如何提升 PHP 性能的？

背景

HHVM 是 Facebook 开发的高性能 PHP 虚拟机，宣称比官方的快9倍，我很好奇，于是抽空简单了解了一下，并整理出这篇文章，希望能回答清楚两方面的问题：

• HHVM 到底靠谱么？是否可以用到产品中？
• 它为什么比官方的 PHP 快很多？到底是如何优化的？

你会怎么做？

在讨论 HHVM 实现原理前，我们先设身处地想想：假设你有个 PHP 写的网站遇到了性能问题，经分析后发现很大一部分资源就耗在 PHP 上，这时你会怎么优化 PHP 性能？

比如可以有以下几种方式：

• 方案1，迁移到性能更好的语言上，如 Java、C++、Go。
• 方案2，通过 RPC 将功能分离出来用其它语言实现，让 PHP 做更少的事情，比如 Twitter 就将大量业务逻辑放到了 Scala 中，前端的 Rails 只负责展现。
• 方案3，写 PHP 扩展，在性能瓶颈地方换 C/C++。
• 方案4，优化 PHP 的性能。

方案1几乎不可行，十年前 Joel 就拿 Netscape 的例子警告过，你将放弃是多年的经验积累，尤其是像 Facebook 这种业务逻辑复杂的产品，PHP 代码实在太多了，据称有2千万行（引用自 [PHP on the Metal with HHVM]），修改起来的成本恐怕比写个虚拟机还大，而且对于一个上千人的团队，从头开始学习也是不可接受的。

方案2是最保险的方案，可以逐步迁移，事实上 Facebook 也在朝这方面努力了，而且还开发了 Thrift 这样的 RPC 解决方案，Facebook 内部主要使用的另一个语言是 C++，从早期的 Thrift 代码就能看出来，因为其它语言的实现都很简陋，没法在生产环境下使用。

目前在 Facebook 中据称 PHP:C++ 已经从 9:1 增加到 7:3 了，加上有 Andrei Alexandrescu 的存在，C++ 在 Facebook 中越来越流行，但这只能解决部分问题，毕竟 C++ 开发成本比 PHP 高得多，不适合用在经常修改的地方，而且太多 RPC 的调用也会严重影响性能。

方案3看起来美好，实际执行起来却很难，一般来说性能瓶颈并不会很显著，大多是不断累加的结果，加上 PHP 扩展开发成本高，这种方案一般只用在公共且变化不大的基础库上，所以这种方案解决不了多少问题。

可以看到，前面3个方案并不能很好地解决问题，所以 Facebook 其实没有选择的余地，只能去考虑 PHP 本身的优化了。

更快的 PHP

既然要优化 PHP，那如何去优化呢？在我看来可以有以下几种方法：

• 方案1，PHP 语言层面的优化。
• 方案2，优化 PHP 的官方实现（也就是 Zend）。
• 方案3，将 PHP 编译成其它语言的 bytecode（字节码），借助其它语言的虚拟机（如 JVM）来运行。
• 方案4，将 PHP 转成 C/C++，然后编译成本地代码。
• 方案5，开发更快的 PHP 虚拟机。

PHP 语言层面的优化是最简单可行的，Facebook 当然想到了，而且还开发了 XHProf 这样的性能分析工具，对于定位性能瓶颈是很有帮助的。

不过 XHProf 还是没能很好解决 Facebook 的问题，所以我们继续看，接下来是方案2，简单来看，Zend 的执行过程可以分为两部分：将 PHP 编译为 opcode、执行 opcode，所以优化 Zend 可以从这两方面来考虑。

优化 opcode 是一种常见的做法，可以避免重复解析 PHP，而且还能做一些静态的编译优化，比如 Zend Optimizer Plus，但由于 PHP 语言的动态性，这种优化方法是有局限性的，乐观估计也只能提升20%的性能。另一种考虑是优化 opcode 架构本身，如基于寄存器的方式，但这种做法修改起来工作量太大，性能提升也不会特别明显（可能30%？），所以投入产出比不高。

另一个方法是优化 opcode 的执行，首先简单提一下 Zend 是如何执行的，Zend 的 interpreter（也叫解释器）在读到 opcode 后，会根据不同的 opcode 调用不同函数（其实有些是 switch，不过为了描述方便我简化了），然后在这个函数中执行各种语言相关的操作（感兴趣的话可看看深入理解 PHP 内核这本书），所以 Zend 中并没有什么复杂封装和间接调用，作为一个解释器来说已经做得很好了。

想要提升 Zend 的执行性能，就需要对程序的底层执行有所解，比如函数调用其实是有开销的，所以能通过 Inline threading 来优化掉，它的原理就像 C 语言中的 inline 关键字那样，但它是在运行时将相关的函数展开，然后依次执行（只是打个比方，实际实现不太一样），同时还避免了 CPU 流水线预测失败导致的浪费。

另外还可以像 JavaScriptCore 和 LuaJIT 那样使用汇编来实现 interpreter，具体细节建议看看 Mike 的解释

但这两种做法修改代价太大，甚至比重写一个还难，尤其是要保证向下兼容，后面提到 PHP 的特点时你就知道了。

开发一个高性能的虚拟机不是件简单的事情，JVM 花了10多年才达到现在的性能，那是否能直接利用这些高性能的虚拟机来优化 PHP 的性能呢？这就是方案3的思路。

其实这种方案早就有人尝试过了，比如 Quercus 和 IBM 的 P8，Quercus 几乎没见有人使用，而 P8 也已经死掉了。Facebook 也曾经调研过这种方式，甚至还出现过不靠谱的传闻 ，但其实 Facebook 在2011年就放弃了。

因为方案3看起来美好，但实际效果却不理想，按照很多大牛的说法（比如 Mike），VM 总是为某个语言优化的，其它语言在上面实现会遇到很多瓶颈，比如动态的方法调用，关于这点在 Dart 的文档中有过介绍，而且据说 Quercus 的性能与 Zend+APC 比差不了太多（[来自The HipHop Compiler for PHP]），所以没太大意义。

不过 OpenJDK 这几年也在努力，最近的 Grall 项目看起来还不错，也有语言在上面取得了显著的效果，但我还没空研究 Grall，所以这里无法判断。

接下来是方案4，它正是 HPHPc（HHVM 的前身）的做法，原理是将 PHP 代码转成 C++，然后编译为本地文件，可以认为是一种 AOT（ahead of time）的方式，关于其中代码转换的技术细节可以参考 The HipHop Compiler for PHP 这篇论文，以下是该论文中的一个截图，可以通过它来大概了解：

这种做法的最大优点是实现简单（相对于一个 VM 来说），而且能做很多编译优化（因为是离线的，慢点也没事），比如上面的例子就将- 1优化掉了，但它很难支持 PHP 中的很多动态的方法，如 eval()、create_function()，因为这就得再内嵌一个 interpreter，成本不小，所以 HPHPc 干脆就直接不支持这些语法。

除了 HPHPc，还有两个类似的项目，一个是 Roadsend，另一个是 phc ，phc 的做法是将 PHP 转成了 C 再编译，以下是它将 file_get_contents($f) 转成 C 代码的例子：

static php_fcall_info fgc_info;
php_fcall_info_init ("file_get_contents", &fgc_info);
php_hash_find (LOCAL_ST, "f", 5863275, &fgc_info.params);
php_call_function (&fgc_info);

话说 phc 作者曾经在博客上哭诉，说他两年前就去 Facebook 演示过 phc 了，还和那里的工程师交流过，结果人家一发布就火了，而自己忙活了4年却默默无闻，现在前途渺茫。。。

Roadsend 也已经不维护了，对于 PHP 这样的动态语言来说，这种做法有很多的局限性，由于无法动态 include，Facebook 将所有文件都编译到了一起，上线时的文件部署居然达到了 1G，越来越不可接受了。

另外有还有一个叫 PHP QB 的项目，由于时间关系我没有看，感觉可能是类似的东东。

所以就只剩下一条路了，那就是写一个更快的 PHP 虚拟机，将一条黑路走到底，或许你和我一样，一开始听到 Facebook 要做一个虚拟机是觉得太离谱，但如果仔细分析就会发现其实也只有这样了。

更快的虚拟机

HHVM 为什么更快？在各种新闻报道中都提到了 JIT 这个关键技术，但其实远没有那么简单，JIT 不是什么神奇的魔法棒，用它轻轻一挥就能提升性能，而且 JIT 这个操作本身也是会耗时的，对于简单的程序没准还比 interpreter 慢，最极端的例子是 LuaJIT 2 的 Interpreter 就稍微比 V8 的 JIT 快，所以并不存在绝对的事情，更多还是在细节问题的处理上，HHVM 的发展历史就是不断优化的历史，你可以从下图看到它是如何一点点超过 HPHPc 的：

值得一提的是在 Android 4.4 中新的虚拟机 ART 就采用的是 AOT 方案（还记得么？前面提到的 HPHPc 就是这种），结果比之前使用 JIT 的 Dalvik 快了一倍，所以说 JIT 也不一定比 AOT 快。

因此这个项目是有很大风险的，如果没有强大的内心和毅力，极有可能半途而废，Google 就曾经想用 JIT 提升 Python 的性能，但最终失败了，对于 Google 来说用到 Python 的地方其实并没什么性能问题（好吧，以前 Google 是用 Python 写过 crawl [参考 In The Plex]，但那都是1996年的事情了）。

比起 Google，Facebook 显然有更大的动力和决心，PHP 是 Facebook 最重要的语言，我们来看看 Facebook 都投入了哪些大牛到这个项目中（不全）：

• Andrei Alexandrescu，『Modern C++ Design』和『C++ Coding Standards』的作者，C++ 领域无可争议的大神
• Keith Adams，负责过 VMware 核心架构，当年 VMware 就派他一人去和 Intel 进行技术合作，足以证明在 VMM 领域他有多了解了
• Drew Paroski，在微软参与过 .NET 虚拟机开发，改进了其中的 JIT
• Jason Evans，开发了 jemalloc，减少了 Firefox 一半的内存消耗
• Sara Golemon，『Extending and Embedding PHP』的作者，PHP 内核专家，这本书估计所有 PHP 高手都看过吧，或许你不知道其实她是女的

虽然没有像 Lars Bak、Mike Pall 这样在虚拟机领域的顶级专家，但如果这些大牛能齐心协力，写个虚拟机还是问题不大的，那么他们将面临什么样的挑战呢？接下来我们一一讨论。

规范是什么？

自己写 PHP 虚拟机要面临的第一个问题就是 PHP 没有语言规范，很多版本间的语法还会不兼容（甚至是小版本号，比如 5.2.1 和 5.2.3），PHP 语言规范究竟如何定义呢？来看一篇来自 IEEE 的说法：

The PHP group claim that they have the final say in the specification of (the language) PHP. This groups specification is an implementation, and there is no prose specification or agreed validation suite.

所以唯一的途径就是老老实实去看 Zend 的实现，好在 HPHPc 中已经痛苦过一次了，所以 HHVM 能直接利用现成，因此这个问题并不算太大。

语言还是扩展？

实现 PHP 语言不仅仅只是实现一个虚拟机那么简单，PHP 语言本身还包括了各种扩展，这些扩展和语言是一体的，Zend 不辞辛劳地实现了各种你可能会用到的功能。如果分析过 PHP 的代码，就会发现它的 C 代码除去空行注释后居然还有80+万行，而你猜其中 Zend 引擎部分有多少？只有不到10万行。

对于开发者来说这不是什么坏事，但对于引擎实现者来说就很悲剧了，我们可以拿 Java 来进行对比，写个 Java 的虚拟机只需实现字节码解释及一些基础的 JNI 调用，Java 绝大部分内置库都是用 Java 实现的，所以如果不考虑性能优化，单从工作量看，实现 PHP 虚拟机比 JVM 要难得多，比如就有人用8千行的 TypeScript 实现了一个 JVM Doppio。

而对于这个问题，HHVM 的解决办法很简单，那就是只实现 Facebook 中用到的，而且同样可以先用 HPHPc 中之前写过的，所以问题也不大。

实现 Interpreter

接下来是 Interpreter 的实现，在解析完 PHP 后会生成 HHVM 自己设计的一种 Bytecode，存储在~/.hhvm.hhbc（SQLite 文件） 中以便重用，在执行 Bytecode 时和 Zend 类似，也是将不同的字节码放到不同的函数中去实现（这种方式在虚拟机中有个专门的称呼：Subroutine threading）

Interpreter 的主体实现在 bytecode.cpp 中，比如 VMExecutionContext::iopAdd 这样的方法，最终执行会根据不同类型来区分，比如 add 操作的实现是在 tv-arith.cpp 中，下面摘抄其中的一小段

if (c2.m_type == KindOfInt64)  return o(c1.m_data.num, c2.m_data.num);
if (c2.m_type == KindOfDouble) return o(c1.m_data.num, c2.m_data.dbl);

正是因为有了 Interpreter，HHVM 在对于 PHP 语法的支持上比 HPHPc 有明显改进，理论上做到完全兼容官方 PHP，但仅这么做在性能并不会比 Zend 好多少，由于无法确定变量类型，所以需要加上类似上面的条件判断语句，但这样的代码不利于现代 CPU 的执行优化，另一个问题是数据都是 boxed 的，每次读取都需要通过类似 m_data.num 和m_data.dbl 的方法来间接获取。

对于这样的问题，就得靠 JIT 来优化了。

实现 JIT 及优化

首先值得一提的是 PHP 的 JIT 之前并非没人尝试过：

• 2008 年就有人用 LLVM 实验过，结果还比原来慢了 21 倍。。。
• 2010 年 IBM 日本研究院基于他们的 JVM 虚拟机代码开发了 P9，性能是官方 PHP 的 2.5 到 9.5 倍，可以看他们的论文Evaluation of a just-in-time compiler retrofitted for PHP。
• 2011 年 Andrei Homescu 基于 RPython 开发过，还写了篇论文 HappyJIT: a tracing JIT compiler for PHP，但测试结果有好有坏，并不理想。

那么究竟什么是 JIT？如何实现一个 JIT？

在动态语言中基本上都会有个 eval 方法，可以传给它一段字符串来执行，JIT 做的就是类似的事情，只不过它要拼接不是字符串，而是不同平台下的机器码，然后进行执行，但如何用 C 来实现呢？可以参考 Eli 写的这个入门例子，以下是文中的一段代码：

unsigned char code[] = {
  0x48, 0x89, 0xf8,                   // mov %rdi, %rax
  0x48, 0x83, 0xc0, 0x04,             // add $4, %rax
  0xc3                                // ret
};
memcpy(m, code, sizeof(code));

然而手工编写机器码很容易出错，所以最好的有一个辅助的库，比如的 Mozilla 的 Nanojit 以及 LuaJIT 的 DynASM，但 HHVM 并没有使用这些，而是自己实现了一个只支持 x64 的（另外还在尝试用 VIXL 来生成 ARM 64 位的），通过 mprotect 的方式来让代码可执行。

但为什么 JIT 代码会更快？你可以想想其实用 C++ 编写的代码最终编译出来也是机器码，如果只是将同样的代码手动转成了机器码，那和 GCC 生成出来的有什么区别呢？虽然前面我们提到了一些针对 CPU 实现原理来优化的技巧，但在 JIT 中更重要的优化是根据类型来生成特定的指令，从而大幅减少指令数和条件判断，下面这张来自 TraceMonkey 的图对此进行了很直观的对比，后面我们将看到 HHVM 中的具体例子：

HHVM 首先通过 interpeter 来执行，那它会在时候使用 JIT 呢？常见的 JIT 触发条件有 2 种：

• trace：记录循环执行次数，如果超过一定数量就对这段代码进行 JIT
• method：记录函数执行次数，如果超过一定数量就对整个函数进行 JIT，甚至直接 inline

关于这两种方法哪种更好在 Lambada 上有个帖子引来了各路大神的讨论，尤其是 Mike Pall（LuaJIT 作者） 、Andreas Gal（Mozilla VP） 和 Brendan Eich（Mozilla CTO）都发表了很多自己的观点，推荐大家围观，我这里就不献丑了。

它们之间的区别不仅仅是编译范围，还有很多细节问题，比如对局部变量的处理，在这里就不展开了

但 HHVM 并没有采用这两种方式，而是自创了一个叫 tracelet 的做法，它是根据类型来划分的，看下面这张图

可以看到它将一个函数划分为了 3 部分，上面 2 部分是用于处理 $k 为整数或字符串两种不同情况的，下面的部分是返回值，所以看起来它主要是根据类型的变化情况来划分 JIT 区域的，具体是如何分析和拆解 Tracelet 的细节可以查看Translator.cpp 中的 Translator::analyze 方法，我还没空看，这里就不讨论了。

当然，要实现高性能的 JIT 还需进行各种尝试和优化，比如最初 HHVM 新增的 tracelet 会放到前面，也就是将上图的 A 和 C 调换位置，后来尝试了一下放到后面，结果性能提示了 14%，因为测试发现这样更容易提前命中响应的类型

JIT 的执行过程是首先将 HHBC 转成 SSA (hhbc-translator.cpp)，然后对 SSA 上做优化（比如 Copy propagation），再生成本地机器码，比如在 X64 下是由 translator-x64.cpp 实现的。

我们用一个简单的例子来看看 HHVM 最终生成的机器码是怎样的，比如下面这个 PHP 函数：

<?php
function a($b){
  echo $b + 2;
}

编译后是这个样子：

mov rcx,0x7200000
mov rdi,rbp
mov rsi,rbx
mov rdx,0x20
call 0x2651dfb <HPHP::Transl::traceCallback(HPHP::ActRec*, HPHP::TypedValue*, long, void*)>
cmp BYTE PTR [rbp-0x8],0xa
jne 0xae00306
; 前面是检查参数是否有效

mov rcx,QWORD PTR [rbp-0x10]           ; 这里将 %rcx 被赋值为1了
mov edi,0x2                            ; 将 %edi（也就是 %rdi 的低32位）赋值为2
add rdi,rcx                            ; 加上 %rcx
call 0x2131f1b <HPHP::print_int(long)> ; 调用 print_int 函数，这时第一个参数 %rdi 的值已经是3了

; 后面暂不讨论
mov BYTE PTR [rbp+0x28],0x8
lea rbx,[rbp+0x20]
test BYTE PTR [r12],0xff
jne 0xae0032a
push QWORD PTR [rbp+0x8]
mov rbp,QWORD PTR [rbp+0x0]
mov rdi,rbp
mov rsi,rbx
mov rdx,QWORD PTR [rsp]
call 0x236b70e <HPHP::JIT::traceRet(HPHP::ActRec*, HPHP::TypedValue*, void*)>
ret 

而 HPHP::print_int 函数的实现是这样的：

void print_int(int64_t i) {
  char buf[256];
  snprintf(buf, 256, "%" PRId64, i);
  echo(buf);
  TRACE(1, "t-x64 output(int): %" PRId64 "\n", i);
}

可以看到 HHVM 编译出来的代码直接使用了 int64_t，避免了 interpreter 中需要判断参数和间接取数据的问题，从而明显提升了性能，最终甚至做到了和 C 编译出来的代码区别不大。

需要注意：HHVM 在 server mode 下，只有超过12个请求就才会触发 JIT，启动过 HHVM 时可以通过加上如下参数来让它首次请求就使用 JIT：

-v Eval.JitWarmupRequests=0

所以在测试性能时需要注意，运行一两次就拿来对比是看不出效果的。

类型推导很麻烦，还是逼迫程序员写清楚吧

JIT 的关键是猜测类型，因此某个变量的类型要是老变就很难优化，于是 HHVM 的工程师开始考虑在 PHP 语法上做手脚，加上类型的支持，推出了一个新语言 - Hack（吐槽一下这名字真不利于 SEO），它的样子如下：

<?hh
class Point2 {
  public float $x, $y;
  function __construct(float $x, float $y) {
    $this->x = $x;
    $this->y = $y;
  }
}
//来自：https://raw.github.com/strangeloop/StrangeLoop2013/master/slides/sessions/Adams-TakingPHPSeriously.pdf

注意到 float 关键字了么？有了静态类型可以让 HHVM 更好地优化性能，但这也意味着和 PHP 语法不兼容，只能使用 HHVM。

其实我个人认为这样做最大的优点是让代码更加易懂，减少无意的犯错，就像 Dart 中的可选类型也是这个初衷，同时还方便了 IDE 识别，据说 Facebook 还在开发一个基于 Web 的 IDE，能协同编辑代码，可以期待一下。

你会使用 HHVM 么？

总的来说，比起之前的 HPHPc，我认为 HHVM 是值得一试的，它是真正的虚拟机，能够更好地支持各种 PHP 的语法，所以改动成本不会更高，而且因为能无缝切换到官方 PHP 版本，所以可以同时启动 FPM 来随时待命，HHVM 还有FastCGI 接口方便调用，只要做好应急备案，风险是可控的，从长远来看是很有希望的。

性能究竟能提升多少我无法确定，需要拿自己的业务代码来进行真实测试，这样才能真正清楚 HHVM 能带来多少收益，尤其是对整体性能提升到底有多少，只有拿到这个数据才能做决策。

最后整理一下可能会遇到的问题，有计划使用的可以参考：

• 扩展问题：如果用到了 PHP 扩展，肯定是要重写的，不过 HHVM 扩展写起来比 Zend 要简单的多，具体细节可以看 wiki 上的例子。
• HHVM Server 的稳定性问题：这种多线程的架构运行一段时间可能会出现内存泄露问题，或者某个没写好的 PHP 直接导致整个进程挂掉，所以需要注意这方面的测试和容灾措施。
• 问题修复困难：HHVM 在出现问题时将比 Zend 难修复，尤其是 JIT 的代码，只能期望它比较稳定了。

P.S. 其实我只了解基本的虚拟机知识，也没写过几行 PHP 代码，很多东西都是写这篇文章时临时去找资料的，由于时间仓促水平有限，必然会有不正确的地方，欢迎大家评论赐教 :)

2014年1月补充：目前 HHVM 在鄙厂的推广势头很不错，推荐大家在2014年尝试一下，尤其是现在兼容性测试已经达到98.58%了，修改成本进一步减小。

引用

• Andrei Alexandrescu on AMA
• Keith Adams 在 HN 上的蛛丝马迹
• How Three Guys Rebuilt the Foundation of Facebook
• PHP on the Metal with HHVM
• Making HPHPi Faster
• HHVM Optimization Tips
• The HipHop Virtual Machine (hhvm) PHP Execution at the Speed of JIT
• Julien Verlaguet, Facebook: Analyzing PHP statically
• Speeding up PHP-based development with HHVM
• Adding an opcode to HHBC

2016/8/24  

今天看了一篇文章，写的不错，拿来分享一下，感谢原作者

PHP优化对于PHP的优化主要是对php.ini中的相关主要参数进行合理调整和设置，以下我们就来看看php.ini中的一些对性能影响较大的参数应该如何设置。

 # vi /etc/php.ini

(1) PHP函数禁用找到：

disable_functions =
该选项可以设置哪些PHP函数是禁止使用的，PHP中有一些函数的风险性还是相当大的，可以直接执行一些系统级脚本命令，如果允许这些函数执行，当PHP程序出现漏洞时，损失是非常严重的！以下我们给出推荐的禁用函数设置：

disable_functions = phpinfo,passthru,exec,system,popen,chroot,escapeshellcmd,escapeshellarg,shell_exec,proc_open,proc_get_status

需注意：如果您的服务器中含有一些系统状态检测的PHP程序，则不要禁用shell_exec,proc_open,proc_get_status等函数。 

(2) PHP脚本执行时间找到：

max_execution_time = 30

该选项设定PHP程序的最大执行时间，如果一个PHP脚本被请求，且该PHP脚本在max_execution_time时间内没能执行完毕，则PHP不再继续执行，直接给客户端返回超时错误。没有特殊需要该选项可保持默认设置30秒，如果您的PHP脚本确实需要长执行时间则可以适当增大该时间设置。 

(3) PHP脚本处理内存占用找到：

memory_limit = 8M

该选项指定PHP脚本处理所能占用的最大内存，默认为8MB，如果您的服务器内存为1GB以上，则该选项可以设置为12MB以获得更快的PHP脚本处理效率。 

(4) PHP全局函数声明找到：

register_globals = Off

网络上很多关于PHP设置的文章都推荐将该选项设置为On，其实这是一种及其危险的设置方法，很可能引起严重的安全性问题。如果没有特殊的需要，强烈推荐保留默认设置！ 

(5) PHP上传文件大小限制找到：

upload_max_filesize = 2M

该选项设定PHP所能允许最大上传文件大小，默认为2MB。根据实际应用需求，可以适当增大该设置。 

(6) Session存储介质找到：

session.save_path

 

如果你的PHP程序使用Session对话，则可以将Session存储位置设置为/dev/shm，/dev/shm是Linux系统独有的TMPFS文件系统，是以内存为主要存储方式的文件系统，比RAMDISK更优秀，因为可以使用DISKSWAP作为补充，而且是系统自带的功能模块，不需要另行配置。想想看，从磁盘IO操作到内存操作，速度会快多少？只是需要注意，存储在/dev/shm的数据，在服务器重启后会全部丢失。不过这对于Session来说是无足轻重的。 

 

 

由于水平有限，有些还是不太明白为什么。如果有更好建议的欢迎随时补充！

0、用单引号代替双引号来包含字符串，这样做会更快一些。因为PHP会在双引号包围的字符串中搜寻变量，单引号则不会，注意：只有echo能这么做，它是一种可以把多个字符串当作参数的“函数”(译注：PHP手册中说echo是语言结构，不是真正的函数，故把函数加上了双引号)。 
PS：在单引号中，PHP不会自动搜寻变量、转义字符等，因此效率上快很多。而一般来说字符串是没有变量的，所以使用双引号会导致性能不佳。

1、如果能将类的方法定义成static，就尽量定义成static，它的速度会提升将近4倍。
PS：事实上，function、method、static method的速度不会有太大差异。具体可见“PHP函数的实现原理及性能分析【转载】”一文。

2、$row[’id’] 的速度是$row[id]的7倍。
PS：不太懂，貌似差异只有后者会先判断id这个宏是否存在，如果不存在则自动转变为字符串。

3、echo 比 print 快，并且使用echo的多重参数(译注：指用逗号而不是句点)代替字符串连接，比如echo $str1,$str2。

PS：如果使用echo $str1.$str2 就会需要 PHP 引擎首先把所有的变量连接起来，然后在输出，而echo $str1,$str2，PHP 引擎就会按照循序输出他们

4、在执行for循环之前确定最大循环数，不要每循环一次都计算最大值，最好运用foreach代替。
PS：像count、strlen这样的操作其实是O(1)的，因此不会带来太多消耗，当然避免每次循环都计算是比较好的策略。最好用foreach代替for，这个效率更高，如果考虑到foreach($array as $var)每次拷贝的消耗，可以使用foreach($array as &$var)这样的引用。

5、注销那些不用的变量尤其是大数组，以便释放内存。
PS：如果没有记错的话，unset($array)不会立刻释放内存，但随时释放是个好习惯。

6、尽量避免使用__get，__set，__autoload。

7、require_once()代价昂贵。
PS：require_once和include_once需要判重，因此效率上要低，但是5.2版本后效率问题已经基本解决。

8、include文件时尽量使用绝对路径，因为它避免了PHP去include_path里查找文件的速度，解析操作系统路径所需的时间会更少。
PS：支持，尽量少用iniset()来设置include_path。

9、如果你想知道脚本开始执行(译注：即服务器端收到客户端请求)的时刻，使用$_SERVER['REQUEST_TIME']要好于time()。
PS：$_SERVER['REQUEST_TIME']保存了发起该请求时刻的时间戳，而time()则返回当前时刻的Unix时间戳。

10、函数代替正则表达式完成相同功能。
PS：这种函数是指strtok、strstr、strpos、str_replace、substr、explode、implode等等。

11、str_replace函数比preg_replace函数快，但strtr函数的效率是str_replace函数的四倍。
PS：字符串操作比正则替换要快。

12、如果一个字符串替换函数，可接受数组或字符作为参数，并且参数长度不太长，那么可以考虑额外写一段替换代码，使得每次传递参数是一个字符，而不是只写一行代码接受数组作为查询和替换的参数。
PS：需要考虑到内置函数和用户自定义函数的开销差异，恐怕这种做法得不偿失。

13、使用选择分支语句(译注：即switch case)好于使用多个if，else if语句。
PS：php中switch支持数值和字符串变量，比C的switch要好用，建议使用。

14、用@屏蔽错误消息的做法非常低效，极其低效。
PS：有什么替代方法吗？没有的话还是不得不用的……

15、打开apache的mod_deflate模块，可以提高网页的浏览速度。

16、数据库连接当使用完毕时应关掉，不要用长连接。
PS：在连接之前，最好设置一下相应的超时机制，例如链接超时、读写超时、等待超时等。

17、错误消息代价昂贵。

18、在方法中递增局部变量，速度是最快的。几乎与在函数中调用局部变量的速度相当。

19、递增一个全局变量要比递增一个局部变量慢2倍。

20、递增一个对象属性(如：$this->prop++)要比递增一个局部变量慢3倍。

21、递增一个未预定义的局部变量要比递增一个预定义的局部变量慢9至10倍。

22、仅定义一个局部变量而没在函数中调用它，同样会减慢速度(其程度相当于递增一个局部变量)。PHP大概会检查看是否存在全局变量。

23、方法调用看来与类中定义的方法的数量无关，因为我(在测试方法之前和之后都)添加了10个方法，但性能上没有变化。

24、派生类中的方法运行起来要快于在基类中定义的同样的方法。

25、调用带有一个参数的空函数，其花费的时间相当于执行7至8次的局部变量递增操作。类似的方法调用所花费的时间接近于15次的局部变量递增操作。

26、Apache解析一个PHP脚本的时间要比解析一个静态HTML页面慢2至10倍。尽量多用静态HTML页面，少用脚本。

27、除非脚本可以缓存，否则每次调用时都会重新编译一次。引入一套PHP缓存机制通常可以提升25%至100%的性能，以免除编译开销。

28、尽量做缓存，可使用memcached。memcached是一款高性能的内存对象缓存系统，可用来加速动态Web应用程序，减轻数据库负载。对运算码 (OP code)的缓存很有用，使得脚本不必为每个请求做重新编译。

29、当操作字符串并需要检验其长度是否满足某种要求时，你想当然地会使用strlen()函数。此函数执行起来相当快，因为它不做任何计算，只返回在zval 结构(C的内置数据结构，用于存储PHP变量)中存储的已知字符串长度。但是，由于strlen()是函数，多多少少会有些慢，因为函数调用会经过诸多步骤，如字母小写化(译注：指函数名小写化，PHP不区分函数名大小写)、哈希查找，会跟随被调用的函数一起执行。在某些情况下，你可以使用isset() 技巧加速执行你的代码。

　　(举例如下)

　　if (strlen($foo) < 5) { echo “Foo is too short”$$ }

　　(与下面的技巧做比较)

　　if (!isset($foo{5})) { echo “Foo is too short”$$ }

　　调用isset()恰巧比strlen()快，因为与后者不同的是，isset()作为一种语言结构，意味着它的执行不需要函数查找和字母小写化。也就是说，实际上在检验字符串长度的顶层代码中你没有花太多开销。
PS：长见识了。

30、当执行变量$i的递增或递减时，$i++会比++$i慢一些。这种差异是PHP特有的，并不适用于其他语言，所以请不要修改你的C或Java代码并指望它们能立即变快，没用的。++$i更快是因为它只需要3条指令(opcodes)，$i++则需要4条指令。后置递增实际上会产生一个临时变量，这个临时变量随后被递增。而前置递增直接在原值上递增。这是最优化处理的一种，正如Zend的PHP优化器所作的那样。牢记这个优化处理不失为一个好主意，因为并不是所有的指令优化器都会做同样的优化处理，并且存在大量没有装配指令优化器的互联网服务提供商(ISPs)和服务器。

31、并不是事必面向对象(OOP)，面向对象往往开销很大，每个方法和对象调用都会消耗很多内存。

32、并非要用类实现所有的数据结构，数组也很有用。

33、不要把方法细分得过多，仔细想想你真正打算重用的是哪些代码?

34、当你需要时，你总能把代码分解成方法。
PS：分解成方法要适当，行数少使用频率高的方法尽量用直接写代码，可以减少函数堆栈开销；且方法嵌套不宜过深，否则大大影响PHP的运行效率。

35、尽量采用大量的PHP内置函数。

36、如果在代码中存在大量耗时的函数，你可以考虑用C扩展的方式实现它们。

37、评估检验(profile)你的代码。检验器会告诉你，代码的哪些部分消耗了多少时间。Xdebug调试器包含了检验程序，评估检验总体上可以显示出代码的瓶颈。

38、mod_zip可作为Apache模块，用来即时压缩你的数据，并可让数据传输量降低80%。

39、在可以用file_get_contents替代file、fopen、feof、fgets等系列方法的情况下，尽量用file_get_contents，因为他的效率高得多!但是要注意file_get_contents在打开一个URL文件时候的PHP版本问题;
PS：这个要记住，尽量使用file_get_contents和file_put_contents，不需要自己判断文件句柄打开是否成功。

40、尽量的少进行文件操作，虽然PHP的文件操作效率也不低的;

41、优化Select SQL语句，在可能的情况下尽量少的进行Insert、Update操作(在update上，我被恶批过);

42、尽可能的使用PHP内部函数(但是我却为了找个PHP里面不存在的函数，浪费了本可以写出一个自定义函数的时间，经验问题啊!);
PS：内置函数比用户自定义函数效率高了将近一个数量级。

43、循环内部不要声明变量，尤其是大变量：对象(这好像不只是PHP里面要注意的问题吧?);
PS：这个必须的，变量过多或者过大时，每次重分配的开销就无法忽略。

44、多维数组尽量不要循环嵌套赋值;

45、在可以用PHP内部字符串操作函数的情况下，不要用正则表达式;

46、foreach效率更高，尽量用foreach代替while和for循环;

47、用单引号替代双引号引用字符串;
PS：晕，这个不就是第一条吗？

48、“用i+=1代替i=i+1。符合c/c++的习惯，效率还高”;

49、对global变量，应该用完就unset()掉;