JSI2性能测试报告

装载效率测试
测试页面见：test/load-eff-test.html

为了测试结果更显客观，我选择了第三方类库的装载测试：
'com.yahoo.yui.*',
'net.conio.prototype.*',
'net.fckeditor.*',
'org.jquery.*',
'us.aculo.script.*'
共22个脚本文件（对于JSI来说还有诺干包定义文件）。

FF2:
标记导入时间（原始方式）:469,469,1047,484,484,437,469,484
同步导入时间:469,453,484,437,469,453
延迟导入时间:921,765,891,906,953,906,922
异步导入时间:859,1093,1141,1031,1641,1125,1078,1093,1157,1141

IE7:
标记导入时间:343,297,297,344,328,328
同步导入时间:281,250,235,235,234,234,250,265
延迟导入时间:922,422,406,391,391,391,407,391
异步导入时间:625,672,672,703,703,672,703,704,688

运行时间测试
测试脚本管理后对新能的影响,影响因素有：全局变量和局部变量的查找时间差异，eval的脚本和script标记直接插入的脚本的可能差异。（这个测试不具有普遍性，这里我主要是测试了一下浏览器对局部变量的访问速度【JSI里面访问变量都是装载单元内的局部变量】，所以故意测试了大量局部变量访问的操作）
测试页面见：test/runtime-eff-test.html

FF2：
jsiTime:		845,	927,	598,	687,	764,
scriptTime:		1432,	950,	1305,	1278,	1219,
evalTime:		1644,	1373,	1322,	1186,	1360,
execTime:		0
dscriptTime:	1432,	950,	1305,	1278,	1219,	

IE7:
jsiTime:	295,	205,	157,	315,	156,	142,	375,	328,	172,	172,	
scriptTime:	172,	172,	189,	140,	251,	187,	217,	203,	172,	234,	
evalTime:	236,	249,	139,	172,	281,	171,	172,	108,	436,	359,	
execTime:	219,	234,	314,	157,	220,	266,	204,	234,	187,	95,	
dscriptTime:	187,	265,	294,	326,	187,	328,	 141,	221,	127,	249,	 

上面的基数太小，随机误差太大，调整原始数据从新测试一遍jsiTime和scriptTime

jsiTime:	576,	658,	688,	703,	611,	608,		
scriptTime:	706,	608,	562,	547,	655,	657,	

总结：
JSI的装载性能表现不错，完全不必计较。
托管代码的运行性能也没有太大区别，不过，因为。JSI托管脚本使用的变量基本都是装载单元内的局部变量（本地声明变量，或者外部依赖的引用或值拷贝），所以，对于FF这类局部变量比全局变量访问速度快不少的解释引擎，JSI托管脚本可以达到更好的运行效率。

有个奇怪的问题，JSI在装载类库时，与传统模式相比，肯定增加了些额外的运算，但是，貌似JSI的同步装载模式下，装载脚本的耗时比传统模式还少（IE 表现明显）？为何？
欢迎大家对这奇怪的现象提出自己的猜想，我稍后贴出我对此问题的看法^_^

评论

15 楼 simon1118 2007-06-28  

希望js2.0出来后，能够有些新的改进！

14 楼 jindw 2007-06-23  

hax可够认真的，这个都测试过。
不过，就是要忽略文件读取的时间。这样就能吧差距表现的大些：）

13 楼 hax 2007-06-23  

本地跟webserver肯定有不同的，特别是ie。
ie读本地文件似乎是同步的，例如

var req = new XMLHttpRequest
req.open(...)
req.onreadystatechange = f1;
req.send()
f2();

从webserver读取，几乎总是先执行f2，再执行f1，但从本地文件系统或者已经在cache里的读取，几乎总是先执行f1然后f2。。。

12 楼 jindw 2007-06-23  

hax 写道

本地文件系统是否有所不同？还是应该在本地起一个web server来测试吧？

这个嘛。直觉告诉我，应该没什么不同吧：（  看来hax比我可要认真的多，^_^
下次发布的时候启咯webserver测试看看。

11 楼 hax 2007-06-22  

本地文件系统是否有所不同？还是应该在本地起一个web server来测试吧？

10 楼 jindw 2007-06-22  

trydofor 写道

1. 机器配置太好,没有网速因素:)

机器配置可不咋的：(
dell的本子，1.6GHZ   512MB
网速，我本来就要剔除这个因素的影响，在本地文件系统上测试的。

9 楼 jindw 2007-06-22  

jianfeng008cn 写道

hax 写道

难不成是因为完全阻塞所以就快了。。。无厘头啊。

是不是该说"独占资源所以快了"，独占不一定会阻塞，快当然有道理.

应该说独占会阻塞吧？笔误？

同步获取资源导致的完全阻塞，确实是一个非常不友好的现象。
所以，对于jsi来说，还是尽量采用延迟装载吧。异步装载也行，但是，异步编程比较麻烦：（

对于dojo，jsvm，最好都打包到一个文件里，别做什么按需装载了。

8 楼 trydofor 2007-06-22  

度量的很细致啊,好像差别不大:)
不负责任的猜想下差异产生的原因:
1. 机器配置太好,没有网速因素:)
2. 浏览器ui线程和request线程的工作机制不同
3. 度量方法上造成假象.

总之,看数据,性能差异不大,使用者可以放心用自己习惯的方式了

7 楼 jianfeng008cn 2007-06-22  

hax 写道

难不成是因为完全阻塞所以就快了。。。无厘头啊。

是不是该说"独占资源所以快了"，独占不一定会阻塞，快当然有道理.

6 楼 jindw 2007-06-22  

hax 写道

难不成是因为完全阻塞所以就快了。。。无厘头啊。

快是有代价的，而且是大家都不想付出的代价：）

所以，异步装载和延迟装载在这里就有了它的价值了：）

不过，这两种装载方式的代码确实还可以进一步优化。放在jsi2beta任务中吗？不知道有无必要，呵呵。

5 楼 hax 2007-06-22  

难不成是因为完全阻塞所以就快了。。。无厘头啊。

4 楼 jindw 2007-06-22  

同上，因为xhr+eval是完全占有了脚本线程的时间，
而script标签引入，它还需要考虑窗口事件，eval + xhr方式相当于独占了脚本线程的时间，所以，再时间上表现的更快。

这只是一个假相，不能说jsi装载真的就比script方式快。但是可以说明的是，JSI装载带来的性能负担很少。

3 楼 hax 2007-06-22  

xhr+eval比script快。。。没有猜想，别卖关子，快说说你的看法。。。

2 楼 jindw 2007-06-22  

hax 写道

如果这样的测试结果的话，异步比同步的优势在哪里呢？

如果说同步会阻塞UI的话，那传统script标签也会阻塞的似乎。。。

传统方式阻塞ui的效果不是一样的：）
大脚本文件阻塞ui的时候，窗口还可以移动，标签页也可以切换，窗口也还会响应重绘事件，但是XMLHttpRequest同步方式阻塞ui那就不同了，和死机差不多：（

这里的测试结果：异步和延迟装载比同步装载慢大约一倍，但是这是本地结果，不考虑网络链接速度的问题。
如果加上网络问题，那么这个差异就会冲淡很多。


说到这个阻塞ui的问题，我去年JSI项目主页放sf空间的时候有着深刻体验：）

1 楼 hax 2007-06-22  

如果这样的测试结果的话，异步比同步的优势在哪里呢？

如果说同步会阻塞UI的话，那传统script标签也会阻塞的似乎。。。