轉(zhuǎn)自: ChinaByte

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

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

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

　　 并不一定。如果我們是在實(shí)現(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)該還不會忘記第一輪的測試。這些案例往往不是在一個頁面里運(yùn)行數(shù)千次，而是單獨(dú)地被調(diào)用數(shù)千次，此時執(zhí)行時間上的差異就顯得不那么明顯。

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

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

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