Beeinflusst die Länge des Schlüssels die Leistung des Wörterbuchs?

Ich würde empfehlen, eine tatsächliche Guid anstelle der String-Darstellung von Guid zu verwenden. Ja, beim Vergleichen von Strings wirkt sich die Länge auf die Anzahl der erforderlichen Operationen aus, da die Strings Zeichen für Zeichen verglichen werden müssen (auf ein Mindestmaß; dies schließt alle Sonderoptionen wie IgnoreCase aus). Die tatsächliche Guid gibt Ihnen nur 16 Byte zum Vergleich und nicht das Minimum von 32 in string .

Davon abgesehen werden Sie sehr wahrscheinlich keinen Unterschied bemerken ... vorzeitige Optimierung und all das. Ich würde einfach für den Guid Schlüssel gehen, da das die Daten sind .

Die tatsächliche Größe eines Objekts in Bezug auf das Abrufen von Werten ist irrelevant. Die Geschwindigkeit der Suche nach Werten ist viel abhängiger von der Geschwindigkeit von zwei Methoden in der übergebenen IEqualityComparer<T> -Instanz

• GetHashcode ()
• Gleich ()

BEARBEITEN

Viele Leute verwenden String als Rechtfertigung für die Aussage, dass eine größere Objektgröße die Nachschlageistung verringert. Dies muss aus mehreren Gründen mit einem Körnchen Salz eingenommen werden.

• Die Leistung der oben genannten Methoden für String verringert sich, wenn die Größe der Zeichenfolge für den Standardvergleicher zunimmt. Nur weil das für System.String zutrifft, heißt das nicht, dass es im Allgemeinen wahr ist
• Sie könnten genauso einfach eine andere IEqualityComparer<String> schreiben, so dass die Länge der Zeichenfolge irrelevant ist.

Ja und nein. Größere Zeichenfolgen erhöhen die Speichergröße eines Wörterbuchs. Und größere Größen bedeuten etwas längere Zeiten, um Hash-Größen zu berechnen.

Aber Sorgen über diese Dinge ist wahrscheinlich vorzeitige Optimierung. Während es langsamer wird, ist es nichts, was Sie wahrscheinlich tatsächlich bemerken werden.

Anscheinend tut es das. Hier ist ein guter Test: Dictionary String Key Test