|
|
隨著Google Chrome的發布，WEB應該說是老樹發新芽，在技術本身并沒有突破的情況下，每一個環節都在以更快的速度進行前進，譬如：
1、JavaScript。現在每一個瀏覽器都在比較誰的執行速度更快，在你追我趕的過程中，毫無疑問，WEB變得更加快速，應用的能力也有越來越強大了。IE6、FF2的時代在現在回顧起來，已經變成老牛拉車的"歷史"了。
2、WEB標準化的速度也越來越快，CSS、HTML5的普及越來越加速，手機也從WAP快速的向WEB標準看齊。原來更多的WEB開發向IE傾斜的趨勢，現在更多的向標準化傾斜。
3、與Flash的爭斗，尤其是apple的旗幟鮮明的不支持Flash的戰斗，使得HTML5的職能從傳統的文字圖片迅猛的向2D、動畫、視頻等領域擴展，私有技術將越來越困難。
所有的這些，都意味著WEB正在朝著第2春進行努力。本文則試圖收集一下目前各主流瀏覽器的JavaScript加速機制，嘗試探討未來JavaScript能走多遠？
Firefox 3.6 Trace JIT 技術
Firefox在Chrome的壓力之下，迅速的發布了TraceMonkey引擎，相關的技術文檔那個可以參考：http://www.ics.uci.edu/%7Efranz/Site/pubs-pdf/ICS-TR-06-16.pdf
這個技術的特點是：
1、JS解釋器首先將源代碼轉變成為JavaScript字節碼（LIR），每一個字節碼都是SSA（Static 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毫無疑問是本次瀏覽器大戰的導火索，其功過還需要時間來驗證。在http://code.google.com/intl/zh-CN/apis/v8/design.html中描述了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"語言中完成的功能，現在開始，可以在腳本語言中支持。
it知識庫：JavaScript 性能優化技術，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
