簡體 English 中英

簡單的Facebook HipHop性能問題

[英]Simple Facebook HipHop Performance Question

原文 2010-02-09 01:44:29 2 6 php/ frameworks/ hiphop

如果我使用PHP Web框架（如CodeIgniter）編寫一個hello world應用程序，然后我編譯它並使用HipHop運行它。 它會比我在django或rails中編寫相同的hello world應用程序運行得更快嗎？

6 個解決方案

HIPHOP將PHP代碼轉換為C ++代碼，需要編譯才能運行。 由於預編譯的代碼運行速度更快，使用的內存更少，因此像python / php這樣的腳本語言可能會在您給出的示例中運行得更快。

但是，HIPHOP不會轉換所有代碼。 php中的很多代碼都是動態的，無法更改為c ++，這意味着您必須記住這些代碼。 如果codeigniter甚至可以使用HIPHOP編譯是另一個問題。

Terry Chay撰寫了一篇關於HIPHOP的大文章，介紹何時使用它，它的局限性和未來。 我會建議閱讀這個，因為它很可能會回答你的大部分問題，並讓你深入了解它是如何工作的:)

http://terrychay.com/article/hiphop-for-faster-php.shtml

在那時，運行時間是無關緊要的。 HipHop專為擴展而設計......意味着數十億的請求。 即使是中等規模的網站，也絕對不需要使用像HipHop這樣的東西。

但更多的問題是......我不認為我們可以看到比較圖表，但我懷疑在這個級別上運行時間會更快。

我不知道django或rails，所以這有點偏離主題。

用普通的php，請求轉到apache，然后轉到mod_php。 mod_php從磁盤加載helloworld.php腳本，解析並標記它，將其編譯為字節碼，然后解釋字節碼，將輸出傳遞回apache，apache將其提供給用戶。
使用php和優化器，第一次運行與普通php大致相同，但編譯后的源代碼存儲在ram中。 然后，對於第二個請求：轉到apache，apache轉到mod_php，apc從ram加載字節碼，解釋它，將其傳遞回apache，返回給用戶。
與hiphop沒有apache，但hiphop本身並沒有解釋器，因此請求直接轉到hiphop並返回給用戶。 所以是的，它更快，因為有幾個原因：
- 更快啟動，因為不需要字節碼編譯 - 該程序已經是機器可讀代碼。 所以沒有每個請求編譯和沒有源文件讀取。
- 沒有翻譯。 機器代碼不一定更快 - 這取決於源轉換（hiphop）的質量和靜態編譯器的質量（g ++）。 與手寫的c代碼相比，hiphop翻譯的代碼並不快，因為由於類型處理等原因會產生一些開銷。
與node.js一樣，也沒有apache。 腳本啟動並直接編譯為機器代碼（因為V8編譯器會這樣做），所以它是AOT（提前）編譯（或者它仍稱為JIT？我真的不知道）。 然后，每個請求都由已編譯的機器代碼直接處理; 所以node.js實際上與hiphop非常相似。 我假設hiphop是多線程的或類似的東西，而節點確實使用IO。

facebook聲稱速度提升了50％，實際上並沒有那么多; 如果你比較語言槍戰的結果，你會看到各種算法的執行速度， php慢5到250倍 。

那么為什么只有50％呢？ 因為......

Web應用程序不僅僅依賴於執行速度，例如IO
php的類型系統可以防止hiphop充分利用c ++的靜態類型
在實踐中，很多php已經是C，因為大多數功能都是內置的或來自擴展。 擴展名用C編程並靜態編譯。

我不確定hello world是否有巨大的性能提升，因為即使有一個好的框架，hello world仍然是如此之小，與所有其他開銷（網絡延遲和內容）相比，執行速度可以忽略不計。

imo：如果你想要速度和易用性，請轉到node.js :)

在任何語言中運行簡單的應用程序總是更快。 當它變得像facebook一樣復雜時，你將面臨許多問題。 PHP緩慢將顯示它的面貌。 同時，將現有代碼轉換為另一種語言不是一種選擇，因為所有邏輯和代碼都不容易轉換為其他語言的語法。 這就是為什么facebook開發人員決定保留舊代碼，並使PHP更快。 這就是他們創建自己的PHP編譯器的原因，稱為HipHop。