Сообщение Re[13]: Регресс производительности при переходе с FW 3.5 SP1 от 16.05.2020 20:02
Изменено 16.05.2020 20:05 Serginio1
Re[13]: Регресс производительности при переходе с FW 3.5 SP1
Здравствуйте, 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 не привел?
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 не привел?
Re[13]: Регресс производительности при переходе с FW 3.5 SP1
Здравствуйте, 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/
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. В полном фреймворке это разные методы, и работают они с разной скоростью.