4

免責事項：たぶんマイクロYAGNI最適化ですが、私に聞いてください..

問題は、大文字と小文字を区別しないルックアップテーブルを実装することです。

  • 私の昔ながらのやり方：辞書にデータを入力するときは、挿入する前にキーを大文字にします。誰かがあなたにルックアップするためのキーを与えるとき、キーを大文字にします。
  • 新しい方法（今日それについて学びました）：辞書はIComparer実装を取り入れているので、を渡すことができStringComparer.InvariantCultureIgnoreCaseます。String.Compare（x、y、SomeIgnoreCaseEnum）に委任すると思います

新しい方法には、辞書に対してルックアップが実行されるn個の場所のそれぞれで.ToUpper（）が実行されることを保証する必要がないという利点があります。

私の質問はどちらがより効率的ですか？ただ好奇心が強いと思います...

更新：挿入された元のキーを知る必要はないことに注意してください。また、使用されるキーは文化にとらわれません。

4

4 に答える 4

3

序数比較を行うことができるため、大文字の方が効率的である可能性があります...しかし、これがパフォーマンスのボトルネックであるとは思えません。いつものように、パフォーマンスに基づいてコードの変更をコミットする前にプロファイリングしてください。

最終的に、文字列比較を指定します。

  • 辞書の使い方にそれほど注意する必要がないことを意味します
  • 元のケーシングがキーに維持されていることを意味し、場合によっては診断に役立ちます
  • キーの処理方法を明示的に事前に指定します。作成の時点で、一度だけ記述することになります。これにより、コード IMO がより明確になります。
于 2010-04-22T08:57:11.867 に答える
1

このエントリを確認してください。それは今日でも有効です。

抜粋: MSDN の「Microsoft .NET 2.0 での文字列の使用に関する新しい推奨事項」から

于 2010-04-22T08:56:48.963 に答える
1

パフォーマンスについてはわかりませんが、StringComparer オプションの方が好みです。ToUpper を使用すると、情報 (元のケーシング) が失われます。確かに、あなたはそれを必要としないかもしれませんが、いつの日かあなたがそうするかもしれません.

また、いつかToUpperに電話するのを忘れて、傷ついた世界にいるでしょう。しかし、私の単体テストはもちろん私を救うでしょう。

于 2010-04-22T08:58:14.507 に答える
0

私は Oded の「Go profile!」を受け入れたでしょう。コメント:)これは明らかな提案のマスターでした。

私のテストから（ソースコードはこちら）

1M の ContainsKey ルックアップの場合、

  • ToUpper アプローチ: 1123 ミリ秒
  • Dictionary(OrdinalIgnoreCaseComparer) : 971 ミリ秒

注入された Comparer オプションを備えた Dictionary を見つけて、パフォーマンスを向上させ、手間を省きました。したがって、ToUpper() はもう必要ありません。

于 2010-04-22T11:23:34.770 に答える