Почему String.GetHashCode () реализован по-разному в 32-битной и 64-битной версиях CLR?

Question

Каковы технические причины различия между 32-разрядной и 64-разрядной версиями string.GetHashCode ()?

Более важно, почему 64-разрядная версия, по-видимому, завершает свой алгоритм, когдаэто встречает NUL-символ?Например, все следующие выражения возвращают true при запуске под 64-битным CLR.

"\0123456789".GetHashCode() == "\0987654321".GetHashCode()
"\0AAAAAAAAA".GetHashCode() == "\0BBBBBBBBB".GetHashCode()
"\0The".GetHashCode() == "\0Game".GetHashCode()

Такое поведение (ошибка?) Проявлялось как проблема производительности, когда мы использовали такие строки в качестве ключей в словаре.

Answer 1

Это похоже на известную проблему, которую Microsoft не исправит :

Поскольку вы упомянули, что это будет серьезным изменением для некоторых программ (даже если они не должны полагаться на это), риск этого был сочтен слишком высоким, чтобы исправить это в текущем выпуске.

Я согласен с тем, что частота столкновений в Словаре по умолчанию будет увеличена этим. Если это отрицательно влияет на производительность ваших приложений, я бы предложил попытаться обойти ее, используя один из конструкторов Dictionary, который использует IEqualityComparer, чтобы вы могли обеспечить более подходящую реализацию GetHashCode. Я знаю, что это не идеально, и хотел бы исправить это в будущей версии .NET Framework.

Источник: Microsoft Connect - String.GetHashCode игнорирует любые символы в строке, кроме первого нулевого байта во время выполнения x64

Answer 2

Эрик Липперт получил замечательный блог на это Любопытная собственность в String

Показано любопытное свойство