Question

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

性能损失为huge，因此图书馆作者继续以此为基础实施。

有什么想法吗？

Answer 1

在做出上述评论后，我决定坚持到底：

来自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，只是解析字符串寻找选择器是一项昂贵的操作。

Answer 2

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

至于为什么，添加一个额外的if / else可能会使id查找性能更高，但是其他css选择器将会变得更慢（仍然无关紧要）。为什么要优化QSA来处理id查找，而有专门的方法可以更快地完成任务。

无论如何，浏览器的目标是速度，而忽略这样的东西会使整体性能图表看起来好多了。在这个基准测试中，它真的是每一毫秒，但对于开发人员......请务必，其他基准测试更重要，QSA性能不再是一个因素。

至于开发人员的便利性，它可以工作，它仍然是如此之快，你不会在实际应用程序中注意到它（我向你展示它在哪些方面是显而易见的，同时仍然是一个理智的程序; o）。

Answer 3

也许是因为如果他们这样做了，他们必须添加一个检查，看看它是否会减慢每个其他查询的简单id查询（没有修饰符）？测试可能不是一个巨大的性能影响，但很难为其他开发人员说话。

我认为如果你担心它，你可以添加一个func，如getObByID，用于检查文档，getElementById，如果它存在则使用它，否则使用选择器。也许开发人员在你可以自己轻松完成时不需要添加这种类型的抽象，开发人员应该记住使用它，并增加学习曲线。

Answer 4

我正在比较getElementById()和querySelector()，发现某人已经完成performance comparisons and calculations。

看起来好像querySelector()每次赢得 ......并且相当数量。

为什么querySelector（'#id'）映射到document.getElementById（'id'）？

4 个答案: