javascript - 基于上下文的 getElementById 比原生 getElementById 慢 1000 倍。像 sizzle 这样的选择器引擎使用更聪明的策略吗？

Question

在将 html block 插入 dom 之前，我对在 dom 外构建 html block 很感兴趣，因此我使用 dynatrace 进行了一些测试。我使用了bobince的方法: Is there any way to find an element in a documentFragment?

我发现它慢了将近 1000 倍(在 IE7 中)，这让我很惊讶。

由于功能非常基础，我想知道 sizzle 等引擎使用的策略。

我想知道是否有一些更有效的方法来进行基于上下文的节点选择？

Answer 1

框架选择器引擎通常是右手优先评估的，所以我希望上下文 ID 选择器 document.getElementById ID 然后检查结果是否在上下文节点中加强 parentNode。这相当快，但它不适用于像本示例这样的文档外 DOM 树。然后，选择器引擎将不得不以极慢的方式执行它，或者不关心(例如，Sizzle 不适用于 DocumentFragment)。

对于实现 Selectors-API 的浏览器，有一种更好的方法可以在我记得的片段中获取 ID。 (IE8、Firefox 3.5、Opera 10、Safari 3.1、Chrome 3)。您可以使用 querySelector 应用 CSS 选择器，将 DocumentFragment 作为上下文节点，因为 API 需要 DocumentFragment 实现 NodeSelector:

alert(frag.querySelector('#myId'))

这不如 getElementById 快，但它的加载速度比 DOM 版本好。

不幸的是，大多数具有 Selectors-API 优化的框架在这​​种情况下或任何其他具有上下文节点的情况下都不会使用它们，因为上下文节点的工作方式在 querySelector[All ] 框架传统上如何实现它，使它们不兼容。

Selectors-API Level 2提出了行为类似于传统框架选择器的“作用域”方法……在可用之前还需要一段时间，但在那之前我们可能不会在现有框架中看到优化的上下文选择器。我认为这是一种耻辱，因为虽然使用上下文节点进行过滤而不是范围界定的 querySelector 方法不是很好，但它仍然非常适用于所有常见情况。