Google Chrome 真的比較快嗎？

Google Chrome 推出已經九天了，網路上的新聞和部落格文章數也數不清，我只想談一件事：Google Chrome 真的比較快嗎？

目前看到的文章大多說二件事：

1. Google Chrome 啟動極快，一按就發
2. Google Chrome 的 V8 Javascript 引擎真的快：cnet 的 Stephan Shankland 跑 V8 的五個 benchmark、Kai Schmerer 跑 SunSpider benchmark，結果都是 Google Chrome 最快。
   

啟動是從自己的硬碟把程式讀入記憶體執行，沒有什麼外在變因，應該大部分的使用者都會有一致的感覺：真的比較快。

Javascript benchmark 是從網站下載 Javascript 到記憶體執行，只計執行時間，不計下載時間，所以可以針對 Javascript 引擎的效能做控制變因的比較。

可是使用者關心的速度真的是 Javascript 跑得快不快嗎？

別儍了！

使用者要的是從「打完網址按 ENTER」到「網頁顯示到可以閱讀的程度」之間的速度，也就是 end-to-end 的速度，Javascript 只是眾多影響速度的因素之一，其他如網路的速度、HTML rendering 的速度、載入和執行 plug-in 的速度等等因素，也都會影響。

這一版的 Google Chrome 的 HTML rendering 是 WebKit 525.13，效能和同是用 WebKit 的 Safari 應該接近。

在 9/3 的記者會，Google 決定不展示 Javascript benchmark，而是實地用一隻小 Javascript 程式去下載和顯示 4 個在台灣蠻流行的網站，反覆幾次，計時。這就是 end-to-end 的速度。

有人說過 Never live demo 嗎？

在記者會前我們試了幾次都是 Google Chrome 小幅領先 Firefox 3.0.1、明顯贏過 IE 7。沒想到在記者會當場， 依序跑完 IE 和 Firefox 之後，跑 Google Chrome 竟然小輸給 Firefox！ 囧rz

眼睛雪亮的讀者大概都猜得出來為什麼會這樣：網路塞車狀況和被連網站當時的負載都會影響跑出來的結果。此外，這些網站用了大量的 Flash，Google Chrome 每頁的 Flash 都要生新的程序來執行，多了一些作業系統的 overhead，即使 Javascript 狂勝結果總共也只是小贏，運氣差一點碰到網路小塞車就輸了...

可見雖然 V8 大勝 Firefox 3.0 或 IE 7 的 Javascript 引擎，並不保證 end-to-end 永遠會贏啊！


後記：

Firefox 3.1 預定會使用 TraceMonkey，目前的 nightly build 裡已經有了，Brendan Eich 做了 TraceMonkey 和 V8 的速度評比，結果是互有優劣，遞迴的程式 V8 快 10 倍，但在日期相關的部分 V8 慢 4.2 倍，處理 64 進位表示的字串也慢了 4 倍。可以想見，TraceMonkey 和 V8 這兩個 open source 的 Javascript 引擎往後在技術上互別苗頭、互學絕招，還有不少好戲可看，這是刺激的時代！

受益的是誰？當然是你我這些愛上網的使用者囉！

嗯... 在 Redmond 的工程師們一定是在天人交戰吧？該自己寫個更厲害的 Javascript 引擎扳回 IE 8 beta 2 在 SunSpider 大輸 Google Chrome 3.8 倍的顏面？還是該把 V8 或是 TraceMonkey 放進 IE？

啊！我知道了，一定是用出各種手段^H^H力量^H^H方法和管道來宣傳 Silverlight，讓全球的網頁開發者唾棄 Javascript！