轉(zhuǎn)自: ChinaByte

顯然，我們可以從測試結(jié)果中得到這樣一個結(jié)論：在一個注重性能的場合，混合運用多種腳本語言一般是沒有意義的。如果要考慮兩次模式匹配測試的結(jié)果差異，也應(yīng)該看到每次迭代都創(chuàng)建了一個RegExp對象的實例。

　　 從這些測試結(jié)果中我們還可以得出另外兩個重要的結(jié)論。首先，如果一種語言本身支持某個功能，直接使用該功能總是要比借用另外一種語言的功能快。第二，如果一種語言以對象形式實現(xiàn)了某種功能（比如VBScript的RegExp對象，JScript的Array和String對象），而第二種語言有更加基本的實現(xiàn)，則第二種語言在這方面速度較快。顯然，創(chuàng)建對象實例的代價是相當(dāng)高的。

　　 其它測試結(jié)果也顯示出這一點。然而，這是否也證明：JScript作為一種更廣泛地使用對象以及支持繼承的語言，它必然要比VBScript慢？

　　 并不一定。如果我們是在實現(xiàn)一個N-層體系，復(fù)雜的業(yè)務(wù)邏輯總是被封裝到組件里，ASP頁面的腳本更主要地是提供整合業(yè)務(wù)對象和前端界面的“粘合劑”支持。換句話說，我們不太會過多地依賴于腳本本身或由腳本提供的對象。

　　 然而在有些場合我們卻不能不用對象。以數(shù)組為例，無論是在VBScript還是JScript中，只要出現(xiàn)對數(shù)組元素的引用，內(nèi)存中就要復(fù)制一個完整的數(shù)組。對于JScript來說，這意味著還要復(fù)制數(shù)組對象的全部屬性。因此，如果程序大量地引用數(shù)組元素，使用JScript的代價顯然比較高。

　　 附注

　　 我們應(yīng)該還不會忘記第一輪的測試。這些案例往往不是在一個頁面里運行數(shù)千次，而是單獨地被調(diào)用數(shù)千次，此時執(zhí)行時間上的差異就顯得不那么明顯。

　　 這樣，下面這個理由可能會使我們草率地放棄本文的測試結(jié)果：如果性能很重要，那么我們就應(yīng)該利用COM+所提供的對象池和二進制代碼等優(yōu)點，由此我們獲得的好處將遠遠超過能夠從一種腳本語言對于另一種腳本語言的優(yōu)勢之中獲得的。如果我們可以認為方案體系的決策是一個性能（COM+）和編碼/維護的方便性（腳本語言）之中二者擇一的命題，那么這個理由確實是合理的。

　　 但在現(xiàn)實中不可能有無數(shù)的開發(fā)者擁有無限的技能，這一事實造成了上述兩個極端之間根據(jù)歷史條件、職員情況、開發(fā)時間等因素所作出的許多折衷和平衡。然而，在一些場合排除使用COM+并不意味著完全不再關(guān)注性能問題。如果由于某些原因COM+不適用，那么本文所提供的測試結(jié)果必將有助于您的決策。

　　 請從這里下載本文代碼：http://www.asptoday.com/articles/images/20000920.zip