最近關於PHP7和HHVM的效能對比,成為了一個熱點的爭議話題,大家都在討論和關注哪一個才是PHP性能提升的未來。
HHVM是一個開源的PHP虛擬機,使用JIT的編譯方式以及其他技術,讓PHP程式碼的執行效能大幅提升。據傳,可以將目前版本的原生PHP程式碼提升5-10倍的執行效能。
HHVM起源於Facebook公司,Facebook早起的許多程式碼是使用PHP來開發的,但是,隨著業務的快速發展,PHP執行效率成為越來越明顯的問題。為了優化執行效率,Facebook在2008年就開始使用HipHop,這是一種PHP執行引擎,最初是為了將Fackbook的大量PHP程式碼轉成 C ,以提高效能和節約資源。使用HipHop的PHP程式碼在效能上有數倍的提升。後來,Facebook將HipHop平台開源,逐漸發展為現在的HHVM。
1. PHP為什麼慢?
PHP的慢是相對於C/C 等級的語言來說,事實上,PHP語言最初的設計,就不是用來解決計算密集型的應用場景。我們可以這樣粗略理解為,PHP為了提升開發效率,而犧牲了執行效率。
我們知道PHP一個很大的特點,就是弱型別特性,也就是說,我可以隨意定義一個變量,然後給它隨意賦值為各種類型的資料。以一個int整數數字為例子,在C語言中:
int num = 200; // 通常是4位元組
但是,如果是PHP定義了一個相同的變量,實際對應的儲存結構則是:
這個結構體將會佔據遠比C變數多得多的內存,PHP定義方式如下:
$a = 200;//這變數將實際佔用比C變數很多倍的儲存空間。
其實對PHP來說,無論儲存什麼類型的數據,都是用上述「通殺」的結構體實現。為了相容於PHP程式設計師的變數類型“亂入”,PHP做到了對開發者的友好,但是對執行引擎很殘酷。單一變數記憶體消耗可能還不明顯,一旦用到PHP的陣列等,則複雜度指數上升(陣列的實作是HashTable)。然後,Zend引擎執行時,將這些PHP程式碼編譯為opcode(PHP的中間字節碼,格式有點類似於組譯),由Zend引擎逐行解釋執行。
無論是字串的連接操作,還是數組的簡單修改等,幾乎都是「PHP程式設計師一句話,Zend引擎跑斷腿」的節奏。因此,同樣的操作,對比C來說,PHP消耗了更多的CPU和記憶體等系統資源。除此之外,還有記憶體自動回收、變數類型判斷等等,都會增加系統資源的消耗。
例如,我用純PHP實作的快速排序函數和原生sort函數,排序10000個整數數字,來做一個耗時對比,結果如下:
##
原生的sort耗時3.44 ms,而我們自己實作的PHP函式sort則是68.79 ms。我們發現,兩者執行效率差距龐大。我的測試方式,是計算函數執行前後的時間間隔,而不是整個PHP腳本從啟動到結束的時間。 PHP腳本啟動和關閉過程,本身有著一系列的初始化和清理工作,也會佔據不少的耗時。通常情況下,PHP執行效率的排行是:
在一般情況下,我們並不建議使用過PHP實現邏輯複雜計算類型的功能,尤其是Web系統流量比較大的場景下。因此,PHP程式設計師應該對PHP的各種原生函數和各類拓展有一個比較廣泛的了解,在具體的功能實現場景中,尋求更原生的解決方案(原生接口或者拓展),而不是自己寫一堆複雜的PHP程式碼來實現這類型功能。
如果有足夠的PHP拓展開發實力,將這類型業務功能重寫為一個PHP拓展,也會大幅提升程式碼的執行效率。這是一個非常好的方式,也被廣泛應用PHP優化。但是,自己寫的PHP業務拓展的缺點也很明顯:
實際上,在網路第一線企業中,更常見的解決方案,並非增加PHP拓展,而用C/C 獨立寫一個服務server,然後PHP透過socket和服務server通訊來完成業務處理,並不將PHP本身和業務耦合在一起。
不過,Web服務大部分的效能瓶頸都在網路傳輸和其他服務server的耗時(例如MySQL等),PHP執行的耗時在整體耗時的佔用比例非常小,所以從業務角度來說,影響可能並不明顯。
2. HHVM提升PHP執行性能的方式
HHVM提升PHP性能的途徑,採用的方式就是取代Zend引擎來產生和執行PHP的中間字節碼(HHVM產生自己格式的中間字節碼),執行時透過JIT(Just In Time,即時編譯是種軟體最佳化技術,指在運行時才會去編譯字節碼為機器碼)轉為機器碼執行。 Zend引擎預設做法,是先編譯為opcode,然後再逐條執行,通常每個指令對應的是C語言層級的函數。如果我們產生大量重複的opcode(純PHP寫的程式碼和函數),對應的則是Zend多次逐條執行這些C程式碼。而JIT所做的則是更進一步,將大量重複執行的字節碼在運行的時候編譯為機器碼,達到提高執行效率的目的。通常,觸發JIT的條件是程式碼或函數被多次重複呼叫。
普通的PHP程式碼,因為無法固定變數的類型,需要額外加入判斷類型的邏輯程式碼,這樣PHP程式碼是不利於CPU執行和最佳化的。因此,HHVM通常需要用到Hack寫法(為了兼容某種特性而額外添加的技巧性質的代碼)的PHP代碼來“配合”,就是為了讓變量類型固定,方便虛擬機編譯執行。 PHP追求以一種形式來容納一切類型,而Hack則可以將被容納的一切標記上確定的類型。
PHP程式碼的Hack寫入法的範例:
#
##上面的例子中,PHP程式碼主要被加上了變數類型。 Hack寫法的整體方向,就是將先前「動態」的寫法變成「靜態」的寫法,來配合HHVM。 HHVM因為它的高效能而吸引了不少人的關注,一些一線網路公司也開始跟進使用。從純語言執行效能測試結果來看,HHVM領先了開發中的PHP7版本不少。不過,從具體業務場景來看,HHVM和PHP7的差距並沒有那麼大,以WordPress開源部落格首頁為測試場景的結果中,他們目前的差距並不明顯。
但是,PHP7目前仍在開發中,就已經可用的技術方案來看,目前的HHVM略勝一籌。不過,HHVM的部署與應用都存在一些的問題:
PHP長期以來飽受批評的效能問題,將會在這個版本得到大幅度的改善。版本中間沒有PHP6哈,據說,是因為這個版本曾經立過項目,後來大部分功能都在5.x的版本裡實現了,為了避免混淆,下一個大版本直接就是PHP7。 (幾年以前,我還看過關於PHP6的書。)
#1. PHP7的介紹
雖然PHP7的正式版本可能要到2015年的10月才發布,不過明年6月應可以看見一個測試版本了,之後是3-4個月的品質保證。
PHP社群的專案計畫如下:
#
因為專案仍然處於開發中的原因,從表格中,可以看見的特性描述都比較模糊。肯定有更多的其他特性,但尚未公佈。以下的這些,是從PHP社群看見的,因為PHP7是一個開發中的項目,以下的這些也不一定準確,不過,不妨礙我們一起來看看。
在上面的特性中,最令人期待的就是PHPng的效能最佳化,PHP社群已經放出了一些效能的測速資料。從數據來看,PHPng的執行效能比起專案啟動之初,已經有接近1倍的提升。這個成績已經非常不錯,況且,最關鍵的是PHP7的優化計畫還有很多尚未完成。等到都全部完成了,相信我們可以看見一個性能更高的PHP7。
這測速資料是來自於PHP社群(wiki.php.net/phpng),而截取了一部分的資料:
對其目前PHP5. 6版,PHPNG的10月效能提升已經非常明顯了:
簡單翻譯下:
2. PHP的弱型別爭議
PHP被爭議的特點很多,但是隨著語言版本的發布和完善,功能和特性方面的批評開始變少了。但是,PHP的「弱類型」特性,卻明顯受到更多的爭議,從HHVM透過Hack的方式直接「去掉」了「弱類型」特性可以看出,HHVM並不喜歡「弱類型」特性。然而,在我們許多PHP程式設計師的眼中,這卻是PHP的重要優點之一。 PHP裡的變因設計得隨性和飄逸,海納百川,一切皆可包容,不是讓語言顯得更為簡單嗎? 實際上,有些人認為它是個嚴重的問題,對於「弱型別」的批評觀點大致如下:受到類似批評的還有Javascript等語言,因為它在這個問題上的表現是一樣的。但是,一門語言最終被大規模使用,必然有它們的道理。 PHP成為Web服務開發的首選腳本語言,Javascript則直接稱霸Web前端領域,能走到這一步都不可能是偶然因素,開發者們用腳投票選擇了它們。程式語言是人類和機器溝通的橋樑,終極追求是實現「人人皆可編程」的宏偉目標。
縱觀語言發展歷史,從0和1的機器碼開始,到組合語言,然後到C語言,再到動態腳本語言PHP。執行效率呈指數下降,但是,學習門檻也呈指數降低。 PHP語言不僅屏蔽了C的記憶體管理和指標的複雜性,而且更進一步屏蔽了變數類型的複雜性。提升了專案開發的效率,降低了學習的門檻,但同時犧牲了一定的執行效能。然後,HHVM的Hack給我們一種「回歸原始」的感覺,重新引入了變數的複雜性。當然,不同的語言解決不同場景下的問題,並不能夠一概而論。
HHVM對PHP的效能提升,讓人眼前一亮,而磨刀霍霍的PHP7則讓人萬分期待。兩者都是極其優秀的開源項目,都在不斷前進和發展中。就目前而言,因為距離PHP7正式版的發布還有比較長的一段時間,所以目前效能優化方案的首選當然是HHVM。不過,就我個人而言,我比較看好PHP7,因為它更能做到PHP程式碼的向下相容。如果兩者性能相差不大,我會選擇簡單的。
推薦教學:《php影片教學》
以上是觀賞PHP7和HHVM的性能之爭的詳細內容。更多資訊請關注PHP中文網其他相關文章!