10

我最近进入了选择器的性能，document.getElementById当一个简单#id的被传递时，当前实现选择器 API 的浏览器不使用这让我很烦恼。

性能损失是巨大的，因此库作者继续以自己的方式实现这一点。

有任何想法吗？

4

4 回答 4

12

在上面发表评论后，我决定继续：

来自 Chromium 源中的 Node.cpp

if (strictParsing && inDocument() && querySelectorList.hasOneSelector() && querySelectorList.first()->m_match == CSSSelector::Id) {
    Element* element = document()->getElementById(querySelectorList.first()->m_value);
    if (element && (isDocumentNode() || element->isDescendantOf(this)) && selectorChecker.checkSelector(querySelectorList.first(), element))
        return element;
    return 0;
}

所以它确实映射到 getElementById，只是解析字符串以查找选择器是一项昂贵的操作。

于 2010-11-28T19:30:21.330 回答
3

太棒了。性能损失是微不足道的......我真的怀疑你是否会每秒进行 100.000 次 id 查找，如果你这样做了，那么 QSA 性能实际上是你应该看的最后一件事。

至于为什么，添加额外的 if/else 可能会使 id 查找性能更高，但其他 css 选择器会慢一点（仍然微不足道）。为什么要优化 QSA 来处理 id 查找，因为无论如何都有专门的方法可以更快地做到这一点。

在任何情况下，浏览器都以速度为目标，而忽略这样的东西会使整体性能图表看起来更好。在这场基准竞赛中，它真的是每一毫秒，但对于开发人员来说......请现实一点，其他基准更为重要，QSA 性能应该不再是一个因素。

至于开发人员的便利，它可以工作，它仍然如此之快，以至于您在实际应用程序中都不会注意到它（我挑战你告诉我它在哪里是视觉上引人注目的，同时仍然是一个理智的程序;o）。

于 2010-11-28T19:31:30.430 回答
0

也许是因为如果他们这样做了，他们将不得不添加一个检查以查看它是否是一个简单的 id 查询（无修饰符），这会减慢所有其他查询的速度？进行测试可能不会对性能造成巨大影响，但很难为其他开发人员说话。

我想如果你担心它，你可以添加一个像 getObByID 这样的函数来检查文档，getElementById，如果它存在就使用它，否则使用选择器。当您可以轻松地自己做时，开发人员可能不觉得有必要添加这种抽象，并且由开发人员记住使用它，并增加学习曲线。

于 2010-11-28T19:22:53.747 回答
0

我在比较getElementById()，querySelector()发现有人已经做了性能比较和计算。

它确实看起来好像每次都querySelector()赢了......而且数量相当可观。

于 2012-06-25T08:37:44.053 回答