各种Javascript优化项目如何影响DOM性能？ [英] How do the various Javascript optimization projects affect DOM performance?
问题描述
纯DOM操作（getElementById / Tagname / Selector，nextChild等）的性能不受影响，因为它们已经在纯C ++中。
JS引擎的改进如何影响性能确实取决于用于性能改进的特定技术以及DOM-> JS桥梁的性能。
前者的一个例子是TraceMonkey的对所有调用都依赖于JS函数。因为跟踪有效地内嵌了执行的路径，所以JS的命中不能被内联的代码（本地代码，真实的多态递归，异常处理程序），跟踪被中止，执行返回到解释器。 TM开发人员正在做很多工作来改进可追踪的代码量（包括处理多态递归），但是通过对任意本地函数（例如DOM）的调用进行实际追踪是不可行的。因此，我相信他们正在考虑在JS中实现更多的DOM（或至少以JS友好的方式）。也就是说，当代码可追溯时，TM可以做得非常好，因为它可以将大多数对象降低到更高效和/或本机的等价物（例如，使用机器内部代替JS号码实现）。
JavaScriptCore（这是SquirrelFish Extreme所在的地方），V8有一个更相似的方法，因为他们都可以立即使用JIT所有的JS代码，并产生更具推测性的代码（例如，如果你在做$ code> a * b 他们生成的代码假定 a 和 b 是数字并且如果它们不是，则可以退回到非常慢的代码）。这跟跟踪有很多好处，也就是说可以使用所有代码，无论是否调用本机代码/抛出异常等，这意味着单个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为尝试和弥补这个问题所做的一件事就是跟踪他们以前看过的内容，并将其纳入执行之路，两者都采用技术组合来进行缓存，特别是热情它们重写指令流的一小部分，而在其他情况下，它们会保持带外高速缓存。广义上说，如果你有代码，那么
ax * ay
V8和JSC将检查隐式类型/结构两次 - 每次访问一次，然后检查 ax 和 ay 都是数字，而TM将生成仅检查 a 类型的代码，并且可以（所有的东西相同）只是加倍 ax 和 ay 而不检查它们是否是数字。 >
如果您正在看纯粹的执行速度，目前有一些混合的包，因为每个引擎似乎在某些任务上比其他任务更好 - TraceMonkey在许多纯数学测试中胜出，V8在大量动态的情况下胜出，如果有混合，JSC胜出。当然，今天这是真的，可能不是明天，因为我们都在努力改善表现。
我提到的另一个问题是DOM< - > JS绑定成本 - 这实际上可以在网络性能上发挥非常重要的作用，其中最好的例子是Safari 3.1 / 2与Chrome在Dromaeo基准测试。 Chrome基于WebKit的Safari 3.1 / 2分支，因此假设类似的DOM性能（编译器差异可能会导致某种程度的差异）是相当安全的。在这个基准测试中，Safari 3.1 / 2实际上击败了Chrome，尽管有一个明显慢得多的JS引擎，这主要是由于JSC / WebCore（WebKit的dom / rendering / etc）和V8 / WebCore之间的更有效的绑定， p>
目前看TM的DOM绑定似乎是不公平的，因为他们还没有完成他们想做的所有工作（唉），所以他们只是回到解释器： - （
There's a lot of capital C, capital S computer science going into Javascript via the Tracemonkey, Squirrelfish, and V8 projects. Do any of these projects (or others) address the performance of DOM operations, or are they purely Javascript computation related?
The performance of pure DOM operations (getElementById/Tagname/Selector, nextChild, etc) are unaffected as they're already in pure C++.
How the JS engine improvements will effect performance does depend to an extent on the particular techniques used for the performance improvements, as well as the performance of the DOM->JS bridge.
An example of the former is TraceMonkey's dependence on all calls being to JS functions. Because a trace effectively inlines the path of execution any point where the JS hits code that cannot be inlined (native code, true polymorphic recursion, exception handlers) the trace is aborted and execution falls back to the interpreter. The TM developers are doing quite a lot of work to improve the amount of code that can be traced (including handling polymorphic recursion) however realistically tracing across calls to arbitrary native functions (eg. the DOM) isn't feasible. For that reason I believe they are looking at implementing more of the DOM in JS (or at least in a JS friendly manner). That said, when code is traceable TM can do an exceptionally good job as it can lower most "objects" to more efficient and/or native equivalents (eg. use machine ints instead of the JS Number implementation).
JavaScriptCore (which is where SquirrelFish Extreme lives) and V8 have a more similar approach in that they both JIT all JS code immediately and produce code that is more speculative (eg. if you are doing a*b they generate code that assumes a and b are numbers and falls back to exceptionally slow code if they aren't). This has a number of benefits over tracing, namely that you can jit all code, regardless as to whether or not it calls native code/throws exceptions, etc, which means a single DOM call won't destroy performance. The downside is that all code is speculative -- TM will inline calls to Math.floor, etc, but the best JSC/V8 can do would be equivalent to a=Math.floor(0.5) -> a=(Math.floor == realFloor) ? inline : Math.floor(0.5) this has costs both in performance and memory usage, it also isn't particularly feasible. The reason for this is the up front compilation, whereas TM only JITs code after it's run (and so knows exactly what function was called) JSC and V8 have no real basis to make such an assumption and basically have to guess (and currently neither attempts this). The one thing that V8 and JSC do to try and compensate for this problem is to track what they've seen in the past and incorporate that into the path of execution, both use a combination of techniques to do this caching, in especially hot cases they rewrite small portions of the instruction stream, and in other cases they keep out of band caches. Broadly speaking if you have code that goes
a.x * a.y
V8 and JSC will check the 'implicit type'/'Structure' twice -- once for each access, and then check that a.x and a.y are both numbers, whereas TM will generate code that checks the type of a only once, and can (all things being equal) just multiply a.x and a.y without checking that they're numbers.
If you're looking at pure execution speed currently there's something of a mixed bag as each engine does appear to do better at certain tasks than others -- TraceMonkey wins in many pure maths tests, V8 wins in heavily dynamic cases, JSC wins if there's a mix. Of course while that's true today it may not be tomorrow as we're all working hard to improve performance.
The other issue i mentioned was the DOM<->JS binding cost -- this can actually play a very significant part in web performance, the best example of this is Safari 3.1/2 vs Chrome at the Dromaeo benchmark. Chrome is based off of the Safari 3.1/2 branch of WebKit so it's reasonably safe to assume similar DOM performance (compiler difference could cause some degree of variance). In this benchmark Safari 3.1/2 actually beats Chrome despite having a JS engine that is clearly much much slower, this is basically due to more efficient bindings between JSC/WebCore (the dom/rendering/etc of WebKit) and V8/WebCore
Currently looking at TM's DOM bindings seems unfair as they haven't completed all the work they want to do (alas) so they just fall back on the interpreter :-(
..
Errmmm, that went on somewhat longer than intended, so short answer to the original question is "it depends" :D
这篇关于各种Javascript优化项目如何影响DOM性能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
