php 是傳統意義上的解釋型語言，而不是編譯型語言。
因此，在命令列或 web 伺服器呼叫直譯器解釋 php **之前，php **就是 php **。php 直譯器會解釋 php 指令碼，把**轉換為一系列 zend 操作碼（機器碼指令，再把這些操作碼交給 zend engine 執行。不過，解釋型語言執行的速度比編譯型語言慢很多，因為每次執行解釋型語言編寫的**時都需要將其轉換為機器碼，消耗額外的系統資源。facebook 意識到了這個效能瓶頸，與 2010 年開始開發乙個叫hphpc的編譯器，把 php **編譯成c++ **。
hphpc編譯器先把php **編譯成c++ **，再把c++ **編譯成可執行檔案，最後把這個可執行檔案部署到生產伺服器。hphpc基本上是成功的，它提公升了facebook的效能，降低了facebook 伺服器的負擔。可是，hphpc對效能的提公升已經到極限了，而且不能完全相容 php 語言，還需要額外話時間編譯，因此對開發者來說，反饋迴路太長。facebook 需要一種混合解決方案，既要進一步提公升效能，又要讓開發速度更快，省去編譯**的時間。
於是，facebook開始開發下一步hphpc，即hhvm。hhvm先把 php **轉換成一種位元組碼中間格式，而且會快取轉換得到位元組碼，然後使用 jit 編譯器轉換並優化快取的位元組碼，將其變成 x86_64 機器碼。hhvm的 jit 編譯器提供了很多底層效能優化措施，這些優化措施是把 php **直接編譯成 c++ **的 hphpc 所不具備的。hhvm 才會及時把位元組碼編譯成機器碼，這一點和傳統的解釋型語言很像。2023年10約，hhvm 的效能超過了 hphpc，而且仍在不斷提公升。
hhvm 的效能超越 hphpc 之後不久，hphpc 就被廢棄了。現在，facebook 的首選 php 直譯器是 hhvm。
hvvm 並不是適合所有人使用。提公升效能有更容易的方式，例如，減少 http 請求數和優化資料庫查詢都是易於實現的方式，能顯著提公升應用的效能，減少響應時間。如果你還沒使用這些優化措施，考慮使用 hhvm 之前先做這些優化吧。facebook 的 hhvm 是為已經做了這些優化措施之後仍想進一步加速應用的開發者準備的。如果你覺得自己需要 hhvm，可以參考以下資源：
檢視 hhvm 相容的 php 擴充套件
facebook對xtrabackup的優化整理
1 adding xtrabackup files 2 integrate xtrabackup into tree 將xtrabackup和主幹 合併，相關改動加入 define xtrabackup保護 3 facebook changes to xtrabackup 主要還是一些編譯相關的修改...
對A 演算法的改進
對sunway程式中的bug所進行的修改 drew 對這個問題進行了如下修正，當子節點在open表和closed表中時，重新計算估價值後，刪除open表中的老的節點，將有新估價值的節點插入open表中，重新排序，經測試效果良好，修改的 如下，紅色部分為drew新增的 新增程序式的相應部分即可。在函式...
C 對C的改進 2
原型宣告的概念 函式要先定義再使用，如果先使用後定義則必須使用原型宣告 include using namespace std int main float add float x,float y 注意 宣告語句必須加分號！位置任意，只是作用域不同 宣告的原因就是告訴編譯環境函式引數的個數,型別和順...