余弘兵 寫:
所以就是說,不論Mozilla 的Trecemonkey 改進了幾多,心理上總是比webkit(或是Google 的V8)慢,反應度也差不少。

Tracemonkey 跟 WebKit 的 JavaScriptCore 還有 V8 比起來,還是有大勝之處呀!
以前 Spidermonkey 是把 JavaScript 編成 bytecode 再去詮釋, JSC 是純粹詮釋 AST,V8 還沒露面。
現在有 Tracemonkey 選擇性地把最常執行的程式碼編譯成原生機械碼。
JSC 首先改寫成 SquirrelFish,也把 JavaScript 編成 bytecode 去詮釋,而非用 AST,接著又改寫成 SquirrelFish Extreme (SFX),也開始做原生碼編譯。
V8 一開始就是編譯成原生碼。
也就是說,目前 Tracemonkey、SFX、和 V8 或多或少都有把 JS 編譯成原生碼。既然編譯成原生碼,就有平台支援的問題。
Tracemonkey 支援 x86、x86-64、和 ARM、
SFX 目前只支援 x86、
V8 支援 x86 和 ARM。
所以 Tracemonkey 的 ARM 支援是為了 Fennec,V8 的 ARM 支援是為了 Android。有多少人因為 Google Chrome 在 x86-64 上面的問題而不爽的?不少人。
再者,Tracemonkey 的 garbage collector 是多執行緒的,而 V8 的 GC 是 stop-the-world 的,所以 GC 只能在一個執行緒。JSC 的 GC 似乎跟 Spidermonkey 一樣,是多執行緒的。
目前再怎麼樣,Tracemonkey 變快 = Firefox 變快。tracing 一旦穩定到可以不只用在 content,也可以用在 chrome,Firefox 在 UI 方面對使用者而言就會更有效率。要是現在的 deCOMtamination 能配上用個(好的) GC 去管理 DOM 物件,便可以把 XPCOM 長年來帶來效能累贅除掉。