Здравствуйте, 4058, Вы писали:

4>Здравствуйте, Serginio1, Вы писали:

4>>>Заменил "X" на "Ё", результаты те-же, не понимаю, что должно было изменится, строки в .NET исторически UTF-16 и один символ ASCII в UTF-16 занимает 2 байта, собственно как и буква "Ё".

S>>https://docs.microsoft.com/en-us/dotnet/api/system.string?redirectedfrom=MSDN&view=netcore-3.1

S>>Только вот алгоритм сравнения может быть разный в зависимости от версии фреймворка и версии юникода

4>Мне трудно представить, что разница может быть настолько существенна, в зависимости от минорной версии юникода (в данном случае мы получается говорим про 5.0 и 5.1).

А Юникод это же не 2 байта. Те же китайские иероглифы в 2 байта не умещаются.
S>>Разница между .Net Core 3.1 и FW 3.5 по твои данным особо то и нет. В пределе погрешности.

4>Так на обычных "пробегах" по коллекции и object.Equals разницы и не должно быть.

Ну ты заменил IndexOf на Equals я и не заметил, прошу прощения. Но разница то есть.

А почему с IndexOf не привел?

Опять же https://habr.com/ru/post/481558/

На Core 3 поиск Int в List стал примерно в 6 раз быстрее, а поиск строк — в 1.4 раза. В Core JIT научился в некоторых ситуациях девирутализировать виртуальные методы, т.е. они вызываются напрямую. Более того, такие методы могут быть заинлайнены. В данном случае девиртуализируется метод EqualityComparer.Default.Equals, который используется для сравнения элементов. В случае с Int всё сводится к вызову Int32.Equals, который к тому же инлайнится. В итоге получившийся код по эффективности близок к прямому сравнению двух Int.

Кстати, раньше я всегда думал, что метод Contains внутри вызывает IndexOf, но оказалось, что это верно только для Core. В полном фреймворке это разные методы, и работают они с разной скоростью.