本文是针对[url]http://www.iteye.com/topic/103313[/url]的回复。
池增加了代码复杂度,反而可能降低效率。我估计,native的new XMLHttpRequest肯定应比你的池要高效。只有IE6,因为是创建一个AcitveX对象,可能较为低效。但是这种效率提高到底有多少?非常值得怀疑。
事实上,对象池技术在多数场合并无必要,例如在java中,只有重量级资源对象,或者反复创建相同的对象并可能影响性能,才会使用对象池。
而在js里面:
1. js对象只是XHR的wrapper,纯粹new一个js对象的开销不会比你复杂的池要大,只会小。
2. XHR自己可能存在优化。实际上,UA自己或者更底层的网络协议层,对于http请求都是有队列的。所以不用你画蛇添足。
3. 就算要用池,浏览器同源请求在同一时刻只能有2个,不同源的也有一定上限(通常10个以下),所以你真的要做池的话,其实应该控制上限。
4. 最重要一点,即使池稍稍提高了效率,与一个HTTP的Network IO相比,肯定可以忽略不计。
总之,XHR的池是毫无意义的——除非你有数据证明它确实提高了效率。
BTW,使用你这个代码的“好处”是,虽然你的这个代码在IE6上会有内存泄漏,但同样是泄漏,因为你重复利用了XHR对象,所以估计你的泄漏量会小。
池增加了代码复杂度,反而可能降低效率。我估计,native的new XMLHttpRequest肯定应比你的池要高效。只有IE6,因为是创建一个AcitveX对象,可能较为低效。但是这种效率提高到底有多少?非常值得怀疑。
事实上,对象池技术在多数场合并无必要,例如在java中,只有重量级资源对象,或者反复创建相同的对象并可能影响性能,才会使用对象池。
而在js里面:
1. js对象只是XHR的wrapper,纯粹new一个js对象的开销不会比你复杂的池要大,只会小。
2. XHR自己可能存在优化。实际上,UA自己或者更底层的网络协议层,对于http请求都是有队列的。所以不用你画蛇添足。
3. 就算要用池,浏览器同源请求在同一时刻只能有2个,不同源的也有一定上限(通常10个以下),所以你真的要做池的话,其实应该控制上限。
4. 最重要一点,即使池稍稍提高了效率,与一个HTTP的Network IO相比,肯定可以忽略不计。
总之,XHR的池是毫无意义的——除非你有数据证明它确实提高了效率。
BTW,使用你这个代码的“好处”是,虽然你的这个代码在IE6上会有内存泄漏,但同样是泄漏,因为你重复利用了XHR对象,所以估计你的泄漏量会小。