转自: ChinaByte
显然，我们可以从测试结果中得到这样一个结论：在一个注重性能的场合，混合运用多种脚本语言一般是没有意义的。如果要考虑两次模式匹配测试的结果差异，也应该看到每次迭代都创建了一个RegExp对象的实例。
从这些测试结果中我们还可以得出另外两个重要的结论。首先，如果一种语言本身支持某个功能，直接使用该功能总是要比借用另外一种语言的功能快。第二，如果一种语言以对象形式实现了某种功能（比如VBScript的RegExp对象，JScript的Array和String对象），而第二种语言有更加基本的实现，则第二种语言在这方面速度较快。显然，创建对象实例的代价是相当高的。
其它测试结果也显示出这一点。然而，这是否也证明：JScript作为一种更广泛地使用对象以及支持继承的语言，它必然要比VBScript慢？
并不一定。如果我们是在实现一个N-层体系，复杂的业务逻辑总是被封装到组件里，ASP页面的脚本更主要地是提供整合业务对象和前端界面的“粘合剂”支持。换句话说，我们不太会过多地依赖于脚本本身或由脚本提供的对象。
然而在有些场合我们却不能不用对象。以数组为例，无论是在VBScript还是JScript中，只要出现对数组元素的引用，内存中就要复制一个完整的数组。对于JScript来说，这意味着还要复制数组对象的全部属性。因此，如果程序大量地引用数组元素，使用JScript的代价显然比较高。
附注
我们应该还不会忘记第一轮的测试。这些案例往往不是在一个页面里运行数千次，而是单独地被调用数千次，此时执行时间上的差异就显得不那么明显。
这样，下面这个理由可能会使我们草率地放弃本文的测试结果：如果性能很重要，那么我们就应该利用COM+所提供的对象池和二进制代码等优点，由此我们获得的好处将远远超过能够从一种脚本语言对于另一种脚本语言的优势之中获得的。如果我们可以认为方案体系的决策是一个性能（COM+）和编码/维护的方便性（脚本语言）之中二者择一的命题，那么这个理由确实是合理的。
但在现实中不可能有无数的开发者拥有无限的技能，这一事实造成了上述两个极端之间根据历史条件、职员情况、开发时间等因素所作出的许多折衷和平衡。然而，在一些场合排除使用COM+并不意味着完全不再关注性能问题。如果由于某些原因COM+不适用，那么本文所提供的测试结果必将有助于您的决策。