10

私は最近、セレクターのパフォーマンスに夢中になっています。現在セレクター API を実装しているブラウザーはdocument.getElementById、単純なパラメーター#idが渡されたときに使用しないことに悩まされています。

パフォーマンスの低下は非常に大きいため、ライブラリの作成者はそれを回避する独自の方法を実装し続けています。

何か案は？

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

Tbh。パフォーマンスの低下はわずかです... 1 秒あたり 100.000 回の ID ルックアップを行うとは思えません。もしそうなら、実際に QSA のパフォーマンスは最後に確認する必要があります。

理由については、追加の if/else を追加すると、ID ルックアップのパフォーマンスが向上する可能性がありますが、他の css セレクターはわずかに (それでも重要ではありません) 遅くなります。とにかく、正確にそれをはるかに高速に行うための専門的な方法があるのに、ID ルックアップを処理するように QSA を最適化する必要はありません。

いずれにせよ、ブラウザは速度を目指しており、このようなものを除外することで、全体的なパフォーマンス チャートの見栄えが大幅に向上します。このベンチマーク レースでは、実際には 1 ミリ秒ごとですが、開発者にとっては... 現実的に考えてください。他のベンチマークの方が重要です。QSA のパフォーマンスはもはや重要な要素であってはなりません。

開発者の利便性に関しては、それは機能しますが、実際のアプリケーションでは気付かないほど高速です (正常なプログラムでありながら、視覚的に目立つ場所を教えてください ;o)。

于 2010-11-28T19:31:30.430 に答える
0

私は比較getElementById()しquerySelector()ていて、誰かがすでにパフォーマンスの比較と計算を行っていることを発見しました。

確かに毎回querySelector()勝っているように見えます...そしてかなりの量です。

于 2012-06-25T08:37:44.053 に答える
0

おそらく、彼らがそれを行った場合、他のすべてのクエリの速度を低下させる単純な id クエリ (修飾子なし) かどうかを確認するチェックを追加する必要があるためでしょうか? テストを行うことは大きなパフォーマンス ヒットではないかもしれませんが、他の開発者に話すのは困難です。

心配な場合は、ドキュメントをチェックするgetObByIDのような機能を追加できると思います.getElementById、存在する場合はそれを使用し、存在しない場合はセレクターを使用します。おそらく開発者は、このタイプの抽象化を自分で簡単に行うことができる場合に追加する必要性を感じていません。それを使用することを覚えて、学習曲線を増やすのは開発者次第です。

于 2010-11-28T19:22:53.747 に答える