各种Javascript优化项目如何影响DOM性能？

有很多的资本C,大写S计算机科学通过的TraceMonkey,金鳞,和V8项目进入的Javascript.这些项目(或其他)中的任何一个是否可以解决DOM操作的性能,还是纯粹与Javascript计算相关？

纯DOM操作(getElementById/Tagname/Selector,nextChild等)的性能不受影响,因为它们已经在纯C++中.

JS引擎改进如何影响性能确实取决于用于性能改进的特定技术以及DOM-> JS桥的性能.

前者的一个例子是TraceMonkey对JS函数的所有调用的依赖.因为跟踪有效地描述了执行路径,JS点击了无法内联的代码(本机代码,真正的多态递归,异常处理程序),所以跟踪将被中止,执行将回退到解释器.TM开发人员正在做很多工作来改进可以跟踪的代码量(包括处理多态递归),但是实际跟踪对任意本机函数(例如DOM)的调用是不可行的.出于这个原因,我相信他们正在考虑在JS中实现更多的DOM(或者至少以JS友好的方式).也就是说,当代码可追溯时,TM可以做得非常好,因为它可以降低大多数"对象"

JavaScriptCore(这是SquirrelFish Extreme所在的地方)和V8有一个更类似的方法,因为他们都立即JIT所有JS代码并生成更具推测性的代码(例如,如果你正在做a*b它们生成代码假设a和b数字并且退回如果它们不是特别慢的代码).这比跟踪有许多好处,即你可以jit所有代码,无论它是否调用本机代码/抛出异常等,这意味着单个DOM调用不会破坏性能.缺点是所有代码都是推测性的 - TM 会内联调用Math.floor等,但最好的JSC/V8可以做到a=Math.floor(0.5)- >a=(Math.floor == realFloor) ? inline : Math.floor(0.5)这在性能和内存使用方面都有成本,但也不是特别可行.这样做的原因是前期编译,而TM只有JIT代码运行后(因此确切地知道调用了什么函数)JSC和V8没有真正的基础来做出这样的假设并且基本上必须猜测(并且当前都没有尝试)这个).V8和JSC尝试和补偿这个问题的一件事是跟踪他们过去看到的内容并将其纳入执行路径,两者都使用一系列技术来执行此缓存,特别是在特别热的情况下它们重写了指令流的一小部分,而在其他情况下,它们保留了带外缓存.从广义上讲,如果你有代码

a.x * a.y

V8和JSC将检查'隐式类型'/'结构'两次 - 每次访问一次,然后检查a.x并且a.y都是数字,而TM将生成a只检查一次类型的代码,并且可以(所有事情都是相等)刚刚乘a.x,并a.y没有检查他们的数字.

如果你正在寻找纯粹的执行速度目前有一些混合包,因为每个引擎似乎在某些任务上比其他任务更好 - TraceMonkey在许多纯数学测试中获胜,V8在动态情况高的情况下获胜,如果有的话,JSC获胜混合物.当然,虽然今天这​​是真的,但可能不是明天,因为我们都在努力提高绩效.

我提到的另一个问题是DOM < - > JS绑定成本 - 这实际上可以在网络性能中起到非常重要的作用,最好的例子就是在Dromaeo基准测试中使用Safari 3.1/2与Chrome.Chrome基于WebKit的Safari 3.1/2分支,因此假设类似的DOM性能(编译器差异可能会导致某种程度的差异)是相当安全的.在这个基准测试中,Safari 3.1/2实际上击败了Chrome,尽管JS引擎显然要慢很多,这主要是因为JSC/WebCore(WebKit的dom/rendering/etc)和V8/WebCore之间的绑定更有效

目前看TM的DOM绑定似乎不公平,因为他们还没有完成他们想要做的所有工作(唉)所以他们只是回到翻译:-(

..

Errmmm,比预期的要长一些,所以对原始问题的简短回答是"它取决于":D