http://www.tuicool.com/articles/m2e2i2

http://www.ibm.com/developerworks/cn/opensource/os-cn-v8engine/

http://www.cppblog.com/woaidongmao/archive/2010/05/17/115577.html

指令碼所需的類和方法已經裝備完畢，接下來就可以做我們的速度測試了。

下面的測試速度是在我的電腦上，Core2 T7100, 1G記憶體上10次測試取平均的結果，編譯環境為VC2005 Express，Release方式。單位為秒。

從圖上可以直觀地看出，V8的速度要比SpiderMonkey快，尤其是指令碼一，V8的速度是SpiderMonkey的10倍還多。

總結

就執行速度而言，V8具有壓倒性的優勢，這和Google的官方宣傳是一致的。

大 小方面，在VC的Release下，V8的動態編譯庫大小為1.39M；SpiderMonkey的動態編譯庫大小為708k，SpiderMonkey 勝出。靜態編譯？嗯，還是算了吧，偶編譯的靜態V8.lib足足有100M，和程式連結時要花費10秒鐘的時間，除錯程式太鬱悶了~~。

對於程式設計簡易程度來說，兩方各有優勢，這個因人而異，我覺得SpiderMonkey的概念更簡潔一點；V8的Template、Scope、Handle等東東還是需要一點時間去理解的。而且還有一點，SpiderMonkey的官方文件比V8的豐富。

如 果各位細心的話，可以發現V8版的addMyClass沒有“析構”函式，也就是說在腳本里建立出來的MyClass是存在記憶體洩漏的！我花了很長時間， 查了N多資料也沒找到如何在V8的GC工作時回收InternalField裡的資料（經試驗，Persistent的MakeWeak方法無效）。目前 的解決方法只有為類提供一個destory函式，在指令碼中顯式呼叫來回收，不過這樣就享受不了垃圾回收了。如果各位有更好的方法，請留言提出哦，非常感 謝！

最後我們還得提到IE的指令碼引擎，呼叫IE指令碼引擎的優點是作業系統整合，所以不用附帶一個DLL或連結一大塊指令碼引擎，這樣釋出的軟體會小一點點，而且ActiveX Scripting技術（請參考本站

MDN上的SpiderMonkey文件確實有點過時了，MDN相當大一部分是社群愛好者自發貢獻的，樓主發現什麼問題也可以直接去改。
SpiderMonkey的api確實很不穩定，一直在改，而且官方也說目前不保證api的穩定，有相當大一部分api會從目前的c風格遷移到c++風格，包括定義屬性，獲取函式引數等等這些還會再改，但是他們已經有計劃在將來逐漸穩定下來。
風險我覺得應該沒什麼。。SpiderMonkey還是有一定社群活躍度的，官方的開發計劃也排了很遠了，就現在對ES6的支援程度SpiderMonkey可能也遠超V8。WP8確實沒有官方支援，不過MS Open Tech已經幫我們搞定了，再等等應該不遠了（也許就幾天了）。

現在jsb裡使用的是從Firefox 28原始碼裡扒出來的版本，不是官方正式釋出的版本，等v31一旦釋出會升級上去。