指令碼所需的類和方法已經裝備完畢，接下來就可以做我們的速度測試了。
下面的測試速度是在我的電腦上，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的豐富。
最後我們還得提到ie
的指令碼引擎
）對於熟悉com程式設計的人來說編寫**也很簡單。但是~~缺點也很明顯，速度不是慢，而是相當慢~~本來偶還想用它也執行一下《指令碼一》的**作為參考的，結果等了一分種無響應後鬱悶地強制退出~~
mdn上的spidermonkey文件確實有點過時了，mdn相當大一部分是社群愛好者自發貢獻的，樓主發現什麼問題也可以直接去改。
spidermonkey的api確實很不穩定，一直在改，而且官方也說目前不保證api的穩定，有相當大一部分api會從目前的c風格遷移到c++風格，包括定義屬性，獲取函式引數等等這些還會再改，但是他們已經有計畫在將來逐漸穩定下來。
風險我覺得應該沒什麼。。spidermonkey還是有一定社群活躍度的，官方的開發計畫也排了很遠了，就現在對es6的支援程度spidermonkey可能也遠超v8。wp8確實沒有官方支援，不過ms open tech已經幫我們搞定了，再等等應該不遠了（也許就幾天了）。
現在jsb裡使用的是從firefox 28原始碼裡扒出來的版本，不是官方正式發布的版本，等
v31一旦發布會公升級上去。
推薦兩篇文章
1.google檔案系統 google file system 摘要 我們設計並實現了google檔案系統，乙個為資料中心的大規模分布應用設計的可伸縮的分布檔案系統。google檔案系統雖然執行在廉價的普遍硬體上，但是可以提供容錯能力，為大量客戶機提供高效能的服務。我們的系統與許多以前的分布檔案系統...
有關「理想」與「現實」的兩篇文章
我這個人比較遲鈍，今天才想到去翻看這兩篇恐怕所有熱心blog事業的人都看過的文章 第一篇是孟巖先生的 放棄理想，未必能成就現實 第二篇是李建忠先生的 認清現實，才能找回理想 以下是我的感想部分 躊躇滿志，然後是在行業內迷失方向不得不 接受現實。然後分析原因，得出的結論是因為 軟體太好復用，以至於弱勢...
看到兩篇文章深有感觸
先來看看別人的經歷 7月份入職的 馬上就4個月了，只改過三個簡單的bug，給我安排的活就是看 寫總結，開始還好，什麼都不知道，就老老實實的看吧，寫吧，可是到後面完全寫不下去了，業務不懂，也沒人講，我就停下來了，至今應該有乙個多月了，又安排我維護乙個其他的模組，我有看看那 我鬱悶的是天天看 我認為應該...