Бенчмаркая ключи Dictionary: забыл IEquatable — получил ×5 и 96 байт на каждый поиск

[Fedorkov]

Буквально мой случай. В далёком 2011 году (это ещё был .NET Framework 3.5) заметил в коде коллеги, что один класс, используемый как ключ в словаре, реализует простой IEquatable. Заменив его на IEquatable<T>, удалось ускорить соответствующую фичу в пару раз.

[NN1]

Пользуйтесь ReSharper или другими анализаторами.

https://www.jetbrains.com/help/inspectopedia/StructLacksIEquatable.Global.html

[Geronom]

Да, решарпер это ловит. У майкрософта тоже есть правило под этот случай — CA1066 (Implement IEquatable when overriding Equals), но по умолчанию оно выключено: в доке прямо "Enabled by default in .NET 10 — No". Так что штатно, без решарпера или включения анализаторов, проблема остаётся незамеченной. https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1066

[mvv-rus]

Для решения вопроса есть несколько вариантов:

…плюс ещё один, в статье не упомянутый: сделать свой компаратор (объект, реализующий IEqualityComparer<TKey>) и передать его в конструктор Dictionary<TKey,TValue>. По моим наблюдениям, в коде самой библиотеки времени выполнения .NET используется довольно часто.

[Geronom]

Спасибо! В выводах он был, а в этом списке я его пропустил. Добавил.

[vvdev]

Я повторюсь, но: великолепная серия статей.

И искренне завидую - у меня на подобное не остаётся ни времени, ни сил.

Просто интересно: а какая мотивация вкладывать столько времени и усилий? Это чистое любопытство или, может быть, побочный продукт реализации каких-либо оптимизаций?

[Geronom]

Спасибо! По работе часто нужны оптимизации, ну и просто хобби — почему бы и нет:)

[vvdev]

Вот я и завидую: пока прогонишь и проанализируешь свои рабочие бенчмарки и поэксперементируешь с кодом - ни на какие другие бенчмарки, и уж тем более статьи, никаких ресурсов не остаётся ;)
А вот почитать - самое то, спасибо.

Успехов.