兩種JavaScript解析引擎效能對比談

隨著Google Chrome的發布，Web應該說是老樹發新芽，在技術本身並沒有突破的情況下，每一個環節都在以更快的速度進行前進，譬如：

◆JavaScript。現在每一個瀏覽器都在比較誰的執行速度更快，在你追我趕的過程中，毫無疑問，Web變得更加快速，應用的能力也有越來越強大了。IE6、FF2的時代在現在回顧起來，已經變成老牛拉車的"曆史"了。

◆Web標準化的速度也越來越快，CSS、HTML 5的普及越來越加速，手機也從WAP快速的向Web標準看齊。原來更多的Web開發向IE傾斜的趨勢，現在更多的向標準化傾斜。

◆與Flash的爭鬥，尤其是apple的旗幟鮮明的不支援Flash，特別是在已經開始預售的iPad上摒棄了Flash，促使HTML 5的職能從傳統的文字圖片迅猛的向2D、動畫、視頻等領域擴充，將對Flash這樣的私人技術構成威脅。BKJIA編者註：近日Adobe高管曾回應說，“HTML 5要想追上Flash，還要一段不短的時間；而且，也有可能永遠追不上”）

所有的這些，都意味著Web正在朝著第2春進行努力。本文則試圖收集一下目前各主流瀏覽器的JavaScript加速機制，嘗試探討未來JavaScript能走多遠？

Firefox 3.6 Trace JIT 技術

Firefox在Chrome的壓力之下，迅速的發布了TraceMonkey引擎，這個技術的特點是：

1、JS解譯器首先將原始碼轉變成為JavaScript位元組碼LIR），每一個位元組碼都是SSAStatic Single Assignment）的。這個位元組碼在某種格式上與Java Bytecode是類似的。不同的是，JavaScript位元組碼缺乏類型資訊，因此，在解釋的過程中，需要根據當前的資料，進行選擇性的處理。因此，每條指令其實都是涉及到更為複雜的運行時類型檢查、動態指派的。

2、TraceMonkey首先以解釋的模式運行指令，但對loop向後跳轉）進行特殊關註：每一個向後跳轉指令意味著一次迴圈的開始，TraceJIT關注的是對迴圈的最佳化，當一次迴圈開始時，TraceMoney試圖對一次迴圈的所有指令進行跟蹤，拉出一條平坦的執行線索(trace tree）。

3、每一條執行線索，對其內部的類型資訊，已經進行了一個假設，在這條線索執行過程中，相關的位元組碼實際上可以理解為已經替換為類型化的位元組碼類似於Java的Bytecode）了。這個類型化的位元組碼再經過簡單的JIT編譯後，直接以機器碼的方式執行。線上索執行開始時，會對類型資訊進行檢查，如果出現類型不符，則可能產生一個新的執行線索。

4、執行線索內在的包含了method inline等技術。

應該說，這種Trace技術，與以往的method level JIT相比，是完全不同的。在適合的應用裡，Trace JIT相比V8等，還會有更大的執行效率提高。

V8

Chrome V8毫無疑問是本次瀏覽器大戰的導火索，其功過還需要時間來驗證。V8的最佳化機制：

◆Fast Property Access。快速對象屬性訪問。其特點是將JS對對象屬性的訪問，從一個動態尋找過程轉換成類似於Java/C++的靜態訪問。毫無疑問，在JavaScript中，對象屬性訪問是最為頻繁的一類操作，這個動態尋找的過程其實是相當之消耗時間的。

◆動態機器碼產生。這個也是與快速屬性訪問相關的。它把動態JS對象轉變為一個類似於Java的靜態布局對象。

◆有效GC。V8提供的是一個stop-the-world, generational, accurate的GC機制。而FF提供的則不是一個分代的GC。在實際應用中，分代的GC相比不分代的GC顯然具有更高的效率。這一點，也是Java Hotspot所必須的。

其它的，Opera 10.50號稱推出了世界上那個最快速的JS引擎，不過，由於沒有文檔資料，暫時並不清楚其內部機制。

預測：

FF的最佳化機制和V8的最佳化機制是不一樣的，兩者完全是可以互補的。因此，可以想象，如果將V8的最佳化機制，如快速對象屬性訪問、分代GC等引入進來，結合Trace JIT技術，相信速度會有更大的提升。同理，對於V8而言，如果將Trace技術引入進來，對運行時的類型進行更準確的預測，那麼，執行速度應該也有更大幅度的提升。

綜上，這些最佳化技術賦予了JavaScript更為強大的處理能力，使得瀏覽器可以更為快速的"下載執行"更大型的應用。使得原本需要在"native"語言中完成的功能，現在開始，可以在指令碼語言中支援。