轉自: ChinaByte

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

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

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

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

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

　　 附注

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

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

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

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