C＃文字列比較（デフォルト）

2つのコレクションを接続したり、 LINQ to Objectsを使用してコレクションをグループ化したりすることがよくあります。 これにより、グループ化またはバインド用に選択されたキーが比較されます。
幸いなことに、これらの操作のコストはO（n）です。 しかし、大規模なコレクションの場合、比較自体の有効性は私たちにとって重要です。 文字列がキーとして選択されている場合、どの比較実装がデフォルトで使用されますか、この実装は文字列に適していますか？

clients.Join(orders, c => c.Name, o => o.ClientName, (c, o) => CreateOrederDto(c, o)); 

ユーザーが明示的に指定しない場合、コンパレーターの実装はどのように選択されますか？

Joinメソッドのソースコードで次の動作を確認できます。

 public static IEnumerable<TResult> Join<TOuter, TInner, TKey, TResult>(this IEnumerable<TOuter> outer, IEnumerable<TInner> inner, Func<TOuter, TKey> outerKeySelector, Func<TInner, TKey> innerKeySelector, Func<TOuter, TInner, TResult> resultSelector) { if (outer == null) throw Error.ArgumentNull("outer"); if (inner == null) throw Error.ArgumentNull("inner"); if (outerKeySelector == null) throw Error.ArgumentNull("outerKeySelector"); if (innerKeySelector == null) throw Error.ArgumentNull("innerKeySelector"); if (resultSelector == null) throw Error.ArgumentNull("resultSelector"); return JoinIterator<TOuter, TInner, TKey, TResult>(outer, inner, outerKeySelector, innerKeySelector, resultSelector, null); } static IEnumerable<TResult> JoinIterator<TOuter, TInner, TKey, TResult>(IEnumerable<TOuter> outer, IEnumerable<TInner> inner, Func<TOuter, TKey> outerKeySelector, Func<TInner, TKey> innerKeySelector, Func<TOuter, TInner, TResult> resultSelector, IEqualityComparer<TKey> comparer) { Lookup<TKey, TInner> lookup = Lookup<TKey, TInner>.CreateForJoin(inner, innerKeySelector, comparer); foreach (TOuter item in outer) { Lookup<TKey, TInner>.Grouping g = lookup.GetGrouping(outerKeySelector(item), false); if (g != null) { for (int i = 0; i < g.count; i++) { yield return resultSelector(item, g.elements[i]); } } } } 

まあ、nullはJoinIteratorメソッドに渡され、内部でチェックは行われません。また、CreateForJoinメソッドにLookupを作成するときに、パラメーターとしてnullが渡されます。

まれにLookupを使用することは、明示的に見つけることができます。 このクラスは、キーによる要素へのアクセスを備えたコレクションであり、キーごとにいくつかの要素を保存できます。存在しないキーによるアクセス試行の場合、 空のコレクションが単に返されます。

CreateForJoinメソッドに興味があります：

 internal static Lookup<TKey, TElement> CreateForJoin(IEnumerable<TElement> source, Func<TElement, TKey> keySelector, IEqualityComparer<TKey> comparer) { Lookup<TKey, TElement> lookup = new Lookup<TKey, TElement>(comparer); ... } Lookup(IEqualityComparer<TKey> comparer) { if (comparer == null) comparer = EqualityComparer<TKey>.Default; this.comparer = comparer; groupings = new Grouping[7]; // 7 -  ,    7 } 

EqualityComparer

ジェネリックインターフェイスIEqualityComparer <T>には、抽象クラスEqualityComparer <T>の形式の基本的な実装があります。このクラスには、特定のクラスTの既定のコンパレータを選択する静的なDefaultプロパティがあります。つまり、T、クラス、構造、または単純型このタイプのオブジェクトの現在のコンパレーターが選択されます。
完全な選択コード （タイプによって異なります ）はかなり華やかですが、JoinとGroupByの作業を理解するという観点からは興味深いものです。

1. バイトの場合、特別なByteEqualityComparerが選択されます。 このクラスは、バイト配列のIndexOf実装を含むため、バイト配列を比較するときのパフォーマンスを改善するように設計されています。
2. TがIEquatable <T>インターフェイスを実装する場合、IEquatable <T> .Equals（T）メソッドの実装の呼び出しに基づいてオブジェクトを比較するGenericEqualityComparer <T>が選択されます。 さらに、呼び出す前に、両方のパラメーターがnullの不等式をチェックします。
3. TがIEquatable <U>を実装するNullable <U>である場合、以前のものと同様で、追加のHasValueチェックを含むNullableEqualityComparer <T>クラスが使用されます。
4. 列挙型の場合、基本型に応じて、EnumEqualityComparer <T>実装の1つが選択されます（long型の場合、独自の特別な実装があります）。これは、列挙値を数値に変換する方法のJIT最適化のみが異なります。
5. それ以外の場合はすべて、Object.Equalsに基づいてオブジェクトを比較するObjectEqualityComparer <T>が使用されます 。 ここでは、すべてが通常どおりです-参照型の場合、リンクの等価性、重要な型の場合-オブジェクトの型の一致（ObjectEqualityComparer <T>の場合は常にtrue）およびオブジェクトのすべてのフィールドの値の一致。

StringクラスはIEquatable <T>インターフェイスを実装するため、文字列を比較するときにこのインターフェイスの実装が呼び出されます。
.NET Coreの場合、コンパレーターを選択するデフォルトの実装は異なります -文字列の場合、 EqualityComparerForStringが選択され、比較に等価==演算子のみが使用されます。

文字列比較

String.Equals（文字列値）メソッドは、文字列参照の等価性、文字列の長さの等価性をチェックし、これらのプロパティに基づいて等価性を計算できない場合、文字列バッファの （ほぼ） バイト比較を呼び出します 。

 [System.Security.SecuritySafeCritical] // auto-generated [ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)] private unsafe static bool EqualsHelper(String strA, String strB) { int length = strA.Length; fixed (char* ap = &strA.m_firstChar) fixed (char* bp = &strB.m_firstChar) { char* a = ap; char* b = bp; //   #if AMD64 //   AMD64   12    3 qword  . while (length >= 12) { if (*(long*)a != *(long*)b) return false; if (*(long*)(a+4) != *(long*)(b+4)) return false; if (*(long*)(a+8) != *(long*)(b+8)) return false; a += 12; b += 12; length -= 12; } #else while (length >= 10) { if (*(int*)a != *(int*)b) return false; if (*(int*)(a+2) != *(int*)(b+2)) return false; if (*(int*)(a+4) != *(int*)(b+4)) return false; if (*(int*)(a+6) != *(int*)(b+6)) return false; if (*(int*)(a+8) != *(int*)(b+8)) return false; a += 10; b += 10; length -= 10; } #endif //          \0 while (length > 0) { if (*(int*)a != *(int*)b) break; a += 2; b += 2; length -= 2; } return (length <= 0); } } 

生産性を高めるために、Microsoft はループを解きほぐしました 。
そのため、デフォルトでは、これらの行の内容のバイト比較が使用されます。 効果的に？ おそらく。 そして、他にどのように文字列を比較できますか？

StringComparer

Stringクラスの場合、.netにはStringComparerコンパレータの独自の抽象実装と、そこから継承されたいくつかのクラスがあり、このクラスの静的プロパティを介してインスタンスにアクセスできます。 3つのタイプの文字列比較には、それぞれ大文字と小文字の区別の有無にかかわらず6つの実装があります。

• CurrentCulture / CurrentCultureIgnoreCase-現在の文化と言語（現在のスレッドの文化）のルールを考慮した、単語による比較
• InvariantCulture / InvariantCultureIgnoreCase-言語と文化および言語の規則を考慮せずに単語に従って比較する（CultureInfo.InvariantCultureを使用）
• Ordinal / OrdinalIgnoreCase-バイト比較

StringComparerはIEqualityComparer <string>を実装するため、その子孫はすべてIEqualityComparer <string>が期待されるパラメーターとして指定できます。
これらの比較方法の説明に何度も出会ったことがありますが、「現在の文化を考慮した言葉による比較」が何を意味するのか、私は本当に疑問に思いませんでした。
バイト比較は、EqualityComparer <String> .Defaultが選択されている場合、またはEqualsメソッドが明示的に呼び出された場合と同じですか？ この場合、 OrdinalComparerクラスが比較を担当します。

 public override bool Equals(string x, string y) { if (Object.ReferenceEquals(x ,y)) return true; if (x == null || y == null) return false; if( _ignoreCase) { if( x.Length != y.Length) { return false; } return (String.Compare(x, y, StringComparison.OrdinalIgnoreCase) == 0); } return x.Equals(y); } 

大文字と小文字を区別する場合、違いはオブジェクト参照の等価性の重複チェックとnullのチェックにあります。 これはそれほど多くありませんが、MSILの観点からは、数十の命令です。

  IL_0000: nop IL_0001: ldarg.0 IL_0002: ldarg.1 IL_0003: call bool [mscorlib]System.Object::ReferenceEquals(object, object) IL_0008: ldc.i4.0 IL_0009: ceq IL_000b: stloc.1 IL_000c: ldloc.1 IL_000d: brtrue.s IL_0013 IL_000f: ldc.i4.1 IL_0010: stloc.0 IL_0011: br.s IL_003e IL_0013: ldarg.0 IL_0014: brfalse.s IL_001f IL_0016: ldarg.1 IL_0017: ldnull IL_0018: ceq IL_001a: ldc.i4.0 IL_001b: ceq IL_001d: br.s IL_0020 IL_001f: ldc.i4.0 IL_0020: nop IL_0021: stloc.1 IL_0022: ldloc.1 IL_0023: brtrue.s IL_0029 IL_0025: ldc.i4.0 IL_0026: stloc.0 IL_0027: br.s IL_003e 

大文字と小文字を区別しない保存はどうですか？ 率直に言って、この操作は文化に依存するため、 ToLowerのようなものは期待していませんでした。 しかし、結果はまだ期待を超えていました。 String.Compare（x、y、StringComparison.OrdinalIgnoreCase）を呼び出すには、次のコードブランチが実行されます。

 case StringComparison.OrdinalIgnoreCase: if (this.Length != value.Length) return false; //      ASCII ,      . if (this.IsAscii() && value.IsAscii()) { return (CompareOrdinalIgnoreCaseHelper(this, value) == 0); } #if FEATURE_COREFX_GLOBALIZATION return CompareInfo.CompareOrdinalIgnoreCase(strA, 0, strA.Length, strB, 0, strB.Length); #else //   return TextInfo.CompareOrdinalIgnoreCase(strA, strB); #endif 

IsAsciiテストを正当化するために、どれほど悪い判断を下す必要があるのでしょうか。
ASCII文字列の場合、検証は実際に文字ごとに実行され、各文字の大文字と小文字がチェックされ、必要に応じて0x20の単純な減算によって大文字に変換されます。

 private unsafe static int CompareOrdinalIgnoreCaseHelper(String strA, String strB) { int length = Math.Min(strA.Length, strB.Length); fixed (char* ap = &strA.m_firstChar) fixed (char* bp = &strB.m_firstChar) { char* a = ap; char* b = bp; while (length != 0) { int charA = *a; int charB = *b; Contract.Assert((charA | charB) <= 0x7F, "strings have to be ASCII"); //            if ((uint)(charA - 'a') <= (uint)('z' - 'a')) charA -= 0x20; if ((uint)(charB - 'a') <= (uint)('z' - 'a')) charB -= 0x20; if (charA != charB) return charA - charB; //   a++; b++; length--; } return strA.Length - strB.Length; } } 

非ASCII文字列の場合、 ネイティブ C ++ コードが呼び出され、条件に応じて、Windowsカーネルからの文字列を比較するためのメソッドを呼び出すことができます（コメントによって判断すると、これはWindows XPでのみ可能です）同じ文字ごとの比較を実行し、各文字を上位に変換するメソッドオペレーティングシステムの文字テーブルのケースベースのレジスタ。

同じコンパレータのパフォーマンスは、縮退の場合、行の1文字を変更することにより、入力データに応じて異なる場合があるため、これは実際にパフォーマンスの問題に関心を引き起こします。

作物はどうですか？ CultureAwareComparerクラスはカルチャを入力として受け入れ、それに基づいて文字列とケースが無視されるかどうかを示すフラグを比較します。 カルチャに関する情報にはCompareInfoプロパティが含まれ、そのオブジェクトにはCultureAwareComparerで使用されるこのカルチャを考慮して文字列を比較するメソッドが含まれます。

 return (_compareInfo.Compare(x, y, _ignoreCase? CompareOptions.IgnoreCase : CompareOptions.None) == 0); 

残念ながら、実際にはネイティブコードが呼び出され、再びカーネルにクロールされて文字列ソート関数が呼び出されるため、内部には興味深いものはありません。 コードの不足を補うために、coreclrの文字列関数で繰り返し見られる抜粋を次に示します。

 // TODO: Remove this workaround after Vista SP2 &/or turkic CompareStringEx() gets fixed on Vista. // If its Vista and we want a turkik sort, then call CompareStringW not CompareStringEx LPCWSTR pLingLocaleName = AvoidVistaTurkishBug ? GetLingusticLocaleName((LPWSTR)lpLocaleName, dwCmpFlags) : lpLocaleName; // TODO: End of workaround for turkish CompareStringEx() on Vista/Win2K8 

つまり、 文化と言語に関する.net文字列の比較は、 常にオペレーティングシステムのカーネルレベルで行われます 。

性能試験

そのような旅の後、私はパフォーマンスの本当の違いに興味を持つようになりました。 当初、私のシナリオは、多数の比較の結果として、シーケンスを結合することでした。 クリーンテストのために、追加の操作を行わずに文字列比較のみを残しました。 GitHubでテストのソースコードを表示または取得できます。 結果は少し浮いていましたが、1,000,000回の10,000回の反復で、信頼区間がなければ十分であると判断しました。

スクリプト	ミリ秒/ 1,000,000操作	相対差
string.Equals	25.8	1倍
EqualityComparer <string> .Default	33.5	1.3倍
StringComparer.Ordinal	29.8	1.16x
StringComparer.OrdinalIgnoreCase	50.3	1.95x
StringComparer.OrdinalIgnoreCase ASCII以外	82.2	3.19x
StringComparer.CurrentCulture	136	5.27x
StringComparer.CurrentCulture非ASCII	174.3	6.76x
StringComparer.CurrentCultureIgnoreCase	134.5	5.21x
StringComparer.CurrentCultureIgnoreCase非ASCII	172.1	6.67x
StringComparer.InvariantCulture	132.2	5.12x
StringComparer.InvariantCulture非ASCII	189.5	7.34x
StringComparer.InvariantCultureIgnoreCase	134.1	5.2倍
StringComparer.InvariantCultureIgnoreCase非ASCII	188	7.29x

結果はコードを確認します-string.Equalsへの明示的な呼び出しは最速で、GenericEqualityComparer <string>は入力パラメーターの追加チェックのために低速です。 OrdinalComparerには追加のチェックもあります。 そして、アンワインドサイクルまたはアンマネージコードメソッドのいずれかが呼び出されます。これは、一般的に、異なるプラットフォームで異なる動作をしますが、カルチャを操作する場合、オペレーティングシステムのカーネルからメソッドを呼び出します。

他の文字列操作の比較

デフォルトでは、最速かつ最も簡単な比較が使用されるように思われますが、プログラマは心配する必要はありません。 実際、これは完全に真実ではありません。 文字列操作は多数あります。 たとえば、文字列が特定の部分文字列で始まるかどうかを判断するには ：

 public Boolean StartsWith(String value) { return StartsWith(value, StringComparison.CurrentCulture); } 

同時に、 部分文字列 （同じように見える） の発生の確認が、バイトごとに実行されます。

 public bool Contains( string value ) { return ( IndexOf(value, StringComparison.Ordinal) >=0 ); } 

この部分文字列の先頭のインデックスを返す部分文字列の出現のチェックは、現在のカルチャでも行われます。

 public int IndexOf(String value) { return IndexOf(value, StringComparison.CurrentCulture); } 

通常、LastIndexOfはネイティブコードを呼び出します。 それで何が起こっていますか？ サティヤだけが知っています。

結論

これらすべての情報をどうしますか？

• まず、多数の比較により、string.Equalsメソッドに既に存在するチェックを複製しない独自の文字列コンパレーターを実装することにより、これらの操作のパフォーマンスを約10％向上させることができます。
• 次に、文字列がキーである場合、ほとんどの比較で約20％のゲインが得られるAscii文字のみを使用することを決定できます。
• 第三に、文化を考慮して比較が適用される場合を理解し、制限する必要があります。 著者はこの比較が最も一般的であると考えたため、多くの場合、コードでStringComparer.InvariantCultureオプションと正確に一致しました。 ただし、ほとんどの場合、StringComparer.Ordinal、または特別な場合にはStringComparer.OrdinalIgnoreCaseを使用するだけで十分です。
• Stringクラスのさまざまなメソッドを使用して、ソースでの動作を再確認することをお勧めします。 おそらく、テストが「TestString」と「AnotherTestString」でテストされた後、コードが実稼働に入ると驚くでしょう。