? ? 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: 10000Possible Remove from MarkedRoot 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 ?nal say in the speci?cation of (the language) PHP. This groups speci?cation is an implementation, and there is no prose speci?cation 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, %rax0x48, 0x83, 0xc0, 0x04, // add $4, %rax0xc3 // 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()掉;

? ?

? ??

總結

以上是生活随笔為你收集整理的PHP 性能优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。