非常小。
第二组测试的结果如下表所示。表中的数值表示不同方案下单个ASP页面的平均执行时间，以秒计（每执行一次ASP页面，测试例程运行多次）。 方案 语言** 字符串翻转（1） 字符串搜索（3） 正则表达式模式匹配（2） 位移操作（3） 简单数学计算（1） 复杂数学计算（3） 数组初始化（1） 记录集遍历（4） VB - VB 0.120 0.346 2.250 0.200 0.287 0.328 2.182 0.524 JS - JS 2.589 0.998 0.138 0.036 0.426 0.499 9.120 0.641 VB - JS 3.066 - 0.221 0.890 - 1.310 - - JS - VB 0.472 - 2.363 0.769 - 0.671 - -
*每种情形用VBScript测试工具页面运行24次，IIS的默认脚本语言是VBScript（没有运行其他的测试工具页面和IIS默认脚本语言组合，因为在最初的运行中它们没有显示出任何次序或时间差异上的影响）。为了减小次序带来的影响，第一、三、四、六测试例程的方案所运行的次序每次都经过改变。上表所显示的是24次运行的平均时间，所有细节数据都可以在下载包的data.xls内找到。
**VB代表VBScript，JS代表JScript。两种语言中的前一种是页面的基本语言，第二种是内嵌代码所用的语言。内嵌代码不用于不需要使用它的场合。 100,000 次迭代 1,000次迭代 10,000次迭代 830个记录的外部循环，14个字段的内部循环（总共11,620次迭代）
这些测试结果更清楚地证实了两种语言的区别所在。从数学计算的结果可以看出，VBScript在这方面要比JScript快——除了位移操作之外（JScript本身支持位移操作，而VBScript不支持）。
两种语言最显著的区别在于字符串翻转、字符串搜索和数组初始化，所有这些测试项目中VBScript都占优势。
字符串翻转操作是VBScript本身所支持的，在该项测试中两者差别尤其明显。在这个测试中，两者的差异之大使得采用内嵌VBScript StrReverse()函数也要比用JScript编写该函数快。
在那些数据改动非常频繁使得手工构造数据失去现实意义的应用中，数据库记录集遍历是一种相当常见操作，因此，上述测试结果中VBScript和JScript在记录集遍历上的差异可能会给那些认为JScript优于VBScript的人一些警示。然而，这种执行时间上的差异也可以用如下事实来辩解，即我们为记录集中的每个记录分别实例化了一个Enumerator对象（总共达到了830次！）。
从第一组测试的结果中已经可以看出，正则表达式模式匹配是JScript绝对优于VBScript的一个地方，所以这一组的测试结果并不令人奇怪。这里的测试结果证实了上一组的测试结果，但差异程度有所放大。
显然，我们可以从测试结果中得到这样一个结论：在一个注重性能的场合，混合运用多种脚本语言一般是没有意义的。如果要考虑两次模式匹配测试的结果差异，也应该看到每次迭代都创建了一个RegExp对象的实例。
从这些测试结果中我们还可以得出另外两个重要的结论。首先，如果一种语言本身支持某个功能，直接使用该功能总是要比借用另外一种语言的功能快。第二，如果一种语言以对象形式实现了某种功能（比如VBScript的RegExp对象，JScript的Array和String对象），而第二种语言有更加基本的实现，则第二种语言在这方面速度较快。显然，创建对象实例的代价是相当高的。
其它测试结果也显示出这一点。然而，这是否也证明：JScript作为一种更广泛地使用对象以及支持继承的语言，它必然要比VBScript慢？
并不一定。如果我们是在实现一个N-层体系，复杂的业务逻辑总是被封装到组件里，ASP页面的脚本更主要地是提供整合业务对象和前端界面的“粘合剂”支持。换句话说，我们不太会过多地依赖于脚本本身或由脚本提供的对象。
然而在有些场合我们却不能不用对象。以数组为例，无论是在VBScript还是JScript中，只要出现对数组元素的引用，内存中就要复制一个完整的数组。对于JScript来说，这意味着还要复制数组对象的全部属性。因此，如果程序大量地引用数组元素，使用JScript的代价显然比较高。
附注
我们应该还不会忘记第一轮的测试。这些案例往往不是在一个页面里运行数千次，而是单独地被调用数千次，此时执行时间上的差异就显得不那么明显。
这样，下面这个理由可能会使我们草率地放弃本文的测试结果：如果性能很重要，那么我们就应该利用COM+所提供的对象池和二进制代码等优点，由此我们获得的好处将远远超过能够从一种脚本语言对于另一种脚本语言的优势之中获得的。如果我们可以认为方案体系的决策是一个性能（COM+）和编码/维护的方便性（脚本语言）之中二者择一的命题，那么这个理由确实是合理的。
但在现实中不可能有无数的开发者拥有无限的技能，这一事实造成了上述两个极端之间根据历史条件、职员情况、开发时间等因素所作出的许多折衷和平衡。然而，在一些场合排除使用COM+并不意味着完全不再关注性能问题。如果由于某些原因COM+不适用，那么本文所提供的测试结果必将有助于您的决策。
第二组测试的结果如下表所示。表中的数值表示不同方案下单个ASP页面的平均执行时间，以秒计（每执行一次ASP页面，测试例程运行多次）。 方案 语言** 字符串翻转（1） 字符串搜索（3） 正则表达式模式匹配（2） 位移操作（3） 简单数学计算（1） 复杂数学计算（3） 数组初始化（1） 记录集遍历（4） VB - VB 0.120 0.346 2.250 0.200 0.287 0.328 2.182 0.524 JS - JS 2.589 0.998 0.138 0.036 0.426 0.499 9.120 0.641 VB - JS 3.066 - 0.221 0.890 - 1.310 - - JS - VB 0.472 - 2.363 0.769 - 0.671 - -
*每种情形用VBScript测试工具页面运行24次，IIS的默认脚本语言是VBScript（没有运行其他的测试工具页面和IIS默认脚本语言组合，因为在最初的运行中它们没有显示出任何次序或时间差异上的影响）。为了减小次序带来的影响，第一、三、四、六测试例程的方案所运行的次序每次都经过改变。上表所显示的是24次运行的平均时间，所有细节数据都可以在下载包的data.xls内找到。
**VB代表VBScript，JS代表JScript。两种语言中的前一种是页面的基本语言，第二种是内嵌代码所用的语言。内嵌代码不用于不需要使用它的场合。 100,000 次迭代 1,000次迭代 10,000次迭代 830个记录的外部循环，14个字段的内部循环（总共11,620次迭代）
这些测试结果更清楚地证实了两种语言的区别所在。从数学计算的结果可以看出，VBScript在这方面要比JScript快——除了位移操作之外（JScript本身支持位移操作，而VBScript不支持）。
两种语言最显著的区别在于字符串翻转、字符串搜索和数组初始化，所有这些测试项目中VBScript都占优势。
字符串翻转操作是VBScript本身所支持的，在该项测试中两者差别尤其明显。在这个测试中，两者的差异之大使得采用内嵌VBScript StrReverse()函数也要比用JScript编写该函数快。
在那些数据改动非常频繁使得手工构造数据失去现实意义的应用中，数据库记录集遍历是一种相当常见操作，因此，上述测试结果中VBScript和JScript在记录集遍历上的差异可能会给那些认为JScript优于VBScript的人一些警示。然而，这种执行时间上的差异也可以用如下事实来辩解，即我们为记录集中的每个记录分别实例化了一个Enumerator对象（总共达到了830次！）。
从第一组测试的结果中已经可以看出，正则表达式模式匹配是JScript绝对优于VBScript的一个地方，所以这一组的测试结果并不令人奇怪。这里的测试结果证实了上一组的测试结果，但差异程度有所放大。
显然，我们可以从测试结果中得到这样一个结论：在一个注重性能的场合，混合运用多种脚本语言一般是没有意义的。如果要考虑两次模式匹配测试的结果差异，也应该看到每次迭代都创建了一个RegExp对象的实例。
从这些测试结果中我们还可以得出另外两个重要的结论。首先，如果一种语言本身支持某个功能，直接使用该功能总是要比借用另外一种语言的功能快。第二，如果一种语言以对象形式实现了某种功能（比如VBScript的RegExp对象，JScript的Array和String对象），而第二种语言有更加基本的实现，则第二种语言在这方面速度较快。显然，创建对象实例的代价是相当高的。
其它测试结果也显示出这一点。然而，这是否也证明：JScript作为一种更广泛地使用对象以及支持继承的语言，它必然要比VBScript慢？
并不一定。如果我们是在实现一个N-层体系，复杂的业务逻辑总是被封装到组件里，ASP页面的脚本更主要地是提供整合业务对象和前端界面的“粘合剂”支持。换句话说，我们不太会过多地依赖于脚本本身或由脚本提供的对象。
然而在有些场合我们却不能不用对象。以数组为例，无论是在VBScript还是JScript中，只要出现对数组元素的引用，内存中就要复制一个完整的数组。对于JScript来说，这意味着还要复制数组对象的全部属性。因此，如果程序大量地引用数组元素，使用JScript的代价显然比较高。
附注
我们应该还不会忘记第一轮的测试。这些案例往往不是在一个页面里运行数千次，而是单独地被调用数千次，此时执行时间上的差异就显得不那么明显。
这样，下面这个理由可能会使我们草率地放弃本文的测试结果：如果性能很重要，那么我们就应该利用COM+所提供的对象池和二进制代码等优点，由此我们获得的好处将远远超过能够从一种脚本语言对于另一种脚本语言的优势之中获得的。如果我们可以认为方案体系的决策是一个性能（COM+）和编码/维护的方便性（脚本语言）之中二者择一的命题，那么这个理由确实是合理的。
但在现实中不可能有无数的开发者拥有无限的技能，这一事实造成了上述两个极端之间根据历史条件、职员情况、开发时间等因素所作出的许多折衷和平衡。然而，在一些场合排除使用COM+并不意味着完全不再关注性能问题。如果由于某些原因COM+不适用，那么本文所提供的测试结果必将有助于您的决策。
