通过 Tracemonkey、Squirrelfish 和 V8 项目，有很多大写 C、大写 S 的计算机科学进入 Javascript。这些项目（或其他项目）中的任何一个都解决了 DOM 操作的性能问题，还是纯粹与 Javascript 计算相关？
【问题讨论】：
标签： javascript dom v8 tracemonkey squirrelfish
它们是纯 JavaScript。除非在 JS 中实现了特定的 DOM 方法调用，否则它们几乎不会产生什么影响（并不是说还没有完成减少此类调用的开销的工作） ）。
DOM 优化是一个完整的“另一锅squirrels monkeys spiders fish...布局甚至渲染引擎都在发挥作用，并且每个浏览器都有自己的实现和优化策略。
【讨论】：
纯 DOM 操作（getElementById/Tagname/Selector、nextChild 等）的性能不受影响，因为它们已经在纯 C++ 中。
JS 引擎的改进将如何影响性能确实在一定程度上取决于用于性能改进的特定技术，以及 DOM->JS 桥的性能。
前者的一个例子是 TraceMonkey 对所有对 JS 函数的调用的依赖。因为在 JS 遇到无法内联的代码（本机代码、真正的多态递归、异常处理程序）的任何点，跟踪都有效地内联了执行路径，所以跟踪被中止，执行回退到解释器。 TM 开发人员正在做大量工作来改进可跟踪的代码量（包括处理多态递归），但实际跟踪对任意本机函数（例如 DOM）的调用是不可行的。出于这个原因，我相信他们正在考虑在 JS 中实现更多的 DOM（或者至少以 JS 友好的方式）。也就是说，当代码可追溯时，TM 可以做得非常好，因为它可以将大多数“对象”降低为更高效和/或本机等效项（例如，使用机器整数而不是 JS Number 实现）。
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如果有混合则获胜。当然，虽然今天确实如此，但明天可能不会，因为我们都在努力提高性能。
我提到的另一个问题是 DOMJS 绑定成本——这实际上可以在 Web 性能中发挥非常重要的作用，最好的例子是 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
【讨论】：