4

大きなテーブルから多数のテーブル列を同時に非表示または表示するjQueryコードを書いています。次のようなコードを使用した方が速いかどうか知りたかったのです。

$("selector 1, selector 2, selector 3").css("display", "none");

または次のようなコード：

$("selector 1").css("display", "none");
$("selector 2").css("display", "none");
$("selector 3").css("display", "none");

そこで、jsperf.com を使用してパフォーマンス テスト ケースを作成しました。これにより、最初のタイプのコード (複数のセレクターを持つ 1 つの長い文字列を使用) は、2 番目のタイプのコード (列を 1 つずつ非表示にする) よりも約 53% 高速であることがわかりました。ただし、書き終わる頃には、次のように境界線上で判読不能になります。

$("#table tr *:nth-child(4), #table tr *:nth-child(5), #table tr *:nth-child(6), #table tr *:nth-child(7), #table tr *:nth-child(8), #table tr *:nth-child(9), #table tr *:nth-child(10), #table tr *:nth-child(11), #table tr *:nth-child(12)").css("display", "none");

私の質問は、jQuery/JS コードにとって、非効率なパフォーマンスと読みやすさの欠如のどちらがより大きな悪であるかということです。私のバックグラウンドは Python であるため、パフォーマンスよりも可読性を重視する傾向があり、53% は現実世界での大幅な低下には見えません。しかし一方で、JS コードを展開したら縮小する予定なので、いずれにせよ読み取り不能になるでしょう...コードを元の読み取り可能または読み取り可能な状態に戻すことができる de-minifier がそこにあることは知っていますが、読めないフォーム。ご覧のとおり、私はこのトピックについて輪になって話すことができます。討論や議論を開始するつもりはないので、jQuery/ JS コミュニティ。

4

4 に答える 4

5

セレクターを配列に格納し、必要なときに結合できます。

var selectors = [
    "selector 1",
    "selector 2",
    "selector 3"
];
$(selectors.join(", ")).css("display", "none");

長いセレクターが機能する理由は、作成される jQuery オブジェクトが 1 つだけであり、ブラウザー メソッドを 1 つしか呼び出せず、速度が向上するためです。私はdocument.querySelectorAll使用されると推測しており、そのセレクター全体を渡して結果を返すことができます。jQueryは、呼び出しn数に対してdocument.querySelectorAllメソッドn数を$().css呼び出します。

別のオプションは、.addメソッドを使用して読みやすさを「改善」することです。

var selectors = $("selector 1");
selectors.add("selector 2");
selectors.add("selector 3");
selectors.css("display", "none");

これは複数のセレクター/cssステートメントよりも高速になると確信していますがdocument.querySelectorAll、1 つの大きなセレクターを使用した の機能ほど高速ではありません。

于 2013-04-09T05:46:37.127 に答える
3

おそらく、そのコードを記述し、両方の世界を持つ別の方法を考えなければならないだけです。例えば：

var nth = [4,5,6,7,8,9,10,11,12];

$('#table tr *')
  .filter(':nth-child('+ nth.join('),:nth-child(') +')')
  .css('display', 'none');
于 2013-04-09T05:10:10.447 に答える
2

おそらく、そのコードがヒットする頻度に依存するはずです (ページの存続期間中に 1 回実行されますか? タイマーまたはクリック イベントに関連付けられているか、または複数回起動する可能性のある何かに関連付けられていますか?)

特定のコードがボトルネックであり、最適化する必要があることを特定しない限り、効率よりも読みやすさを常に優先します。時期尚早の最適化に関する古典的なプログラミングの教訓を思い出してください。

また、jsperf テストはブラウザーやクライアント (特に古い IE やモバイル) によって大きく異なる可能性があることに注意してください。ECMA 実装の違いにより、最新バージョンの Firefox と Chrome の間でもパフォーマンスの大幅な違いが見られることがあります。

最後に、53% の差はパーセンテージで表すとかなりの差のように聞こえますが、ミリ秒単位で時間を見て、これがアプリの潜在的なボトルネックになる可能性があるかどうかを自分で判断してください。

于 2013-04-09T05:04:57.343 に答える
2

パフォーマンスよりも読みやすさを重視します。やっぱりあなたはJSを使っています。とはいえ、読みやすい方法でもパフォーマンスを向上させることができます。たとえば、インラインの巨大な文字列ではなく、よりわかりやすい for ループを使用してこのセレクターを生成します。

さらに、縮小化では、コードを上書きしないでください。変更がある場合は、縮小されていないバージョンに戻って編集し、再度縮小します。縮小されたコードは、人間の目ではなくブラウザ用です。したがって、読みやすさに関するコメントは関係ありません。

于 2013-04-09T05:05:13.923 に答える