Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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