Производительность запросов HashSet <T>и Linq

Question

В течение прошлой недели я получил некоторый код и меня попросили улучшить производительность.Итак, началось с работы, но вскоре я увидел, что они используют множество HashSet<T> объектов для хранения больших коллекций объектов (от 10000 до более 100000 объектов).В коде они используют HashSet<T> из соображений производительности.

Единственное, что они делают, - это заполняют HashSet объектами, а затем используют некоторый Linq для выполнения запросов между несколькими коллекциями.Большинство запросов присоединяются к 1 или n HashSet или извлекают определенные объекты из коллекции с помощью First() или Where().

Интересно, получим ли мы какое-либо преимущество в производительности по сравнению с обычнымList<T>?Поскольку все методы расширения Linq, которые они используют в коде, написаны для IEnumerable<T>.

В Интернете много статей говорят, что List будет быстрее, но некоторые говорят, что HashSet обрабатывает огромные коллекции гораздо лучше, чем List.

Надеюсь, что кто-то может дать мне больше советов.

Спасибо.

Answer 1

Если вы используете только запросы LINQ, вы не получаете никаких преимуществ, так как вы просто просматриваете всю коллекцию.Фактически, возможно, что List<T> - лучшая производительность из-за непрерывного внутреннего хранилища.

Чтобы получить преимущество от HashSet<T>, вам нужно использовать методы ISet<T>, в идеале сHashSet<T>, так как, глядя на код, он оптимизирован для этого случая.Кроме того, операции будут выполняться быстрее, в которых используются хеш-коды объектов-членов, например, тестирование на равенство, поскольку производительность HashSet<T> основана на характеристике производительности O (1) для поиска хеш-кодов.Операции, которые не используют хэш-коды членов, такие как фильтрация свойства элемента по сравнению с самими членами, должны быть операцией O (N), что делает ее такой же, как List<T>.