質問のタイトルがほぼすべてを物語っています: キーが長いとルックアップが遅くなりますか? は:
someObj["abcdefghijklmnopqrstuv"]
より遅い:
someObj["a"]
別のサブ質問は、キーとして使用される文字列内の文字のタイプが重要かどうかです。英数字のキー文字列は高速ですか?
私はいくつかの調査を試みました。これについてはオンラインであまり情報がないようです。どんな助け/洞察も非常に高く評価されます。
質問のタイトルがほぼすべてを物語っています: キーが長いとルックアップが遅くなりますか? は:
someObj["abcdefghijklmnopqrstuv"]
より遅い:
someObj["a"]
別のサブ質問は、キーとして使用される文字列内の文字のタイプが重要かどうかです。英数字のキー文字列は高速ですか?
私はいくつかの調査を試みました。これについてはオンラインであまり情報がないようです。どんな助け/洞察も非常に高く評価されます。
一般的にいいえ。大部分の言語では、文字列リテラルは 'インターン化' されています。これにより、文字列リテラルがハッシュ化され、検索が大幅に高速化されます。一般に、異なる JavaScript エンジン間には多少の不一致がある可能性がありますが、全体として、それらが適切に実装されていれば (咳IE咳)、ほぼ同等のはずです。特に JavaScript エンジンは絶えず開発されているため、(おそらく) 最適化するのは簡単であり、状況は時間の経過とともに改善されます。
ただし、一部のエンジンでは、インターンされる文字列の長さに制限もあります。さまざまなブラウザーでの YMMV。また、jsperf テスト (質問のコメントにリンクされています) からの洞察も見ることができます。明らかに、Firefox ははるかに積極的なインターンを行います。
文字の種類に関しては、文字セットに関係なく、文字列は単なるバイトの束として扱われるため、おそらく問題にはなりません。エンジンは、ドット表記で使用できるキーを最適化する可能性がありますが、その証拠はありません。
V8 javascript エンジンを使用する Chrome について話している場合、パフォーマンスは同じです。V8 設計仕様に基づくと、「高速プロパティ アクセス」と「動的マシン コード生成」から、最終的にこれらのキーが他の c++ クラス変数としてコンパイルされることがわかります。