Сообщение Re[4]: Регресс производительности при переходе с FW 3.5 SP1 от 17.05.2020 15:09
Изменено 17.05.2020 17:18 4058
Re[4]: Регресс производительности при переходе с FW 3.5 SP1
Здравствуйте, VladD2, Вы писали:
VD>Я как раз внимательно все прочел. И в названии темы String.IndexOf не присутствует. Название вон сверху.
В root-овом сообщении присутствует:
http://rsdn.org/forum/dotnet/7731686.1
VD> ... Ну. одна функция стала по медленнее. Никакого отношения к производительности самого дотнета это не имеет. Производительность зависит от кучи фаторов. И главное это работа компилятора (джит, нген) и сборщика мусора.
В данном случае эта функция использовалась часто, никто не говорит про .NET в целом, речь конкретно про String.IndexOf и заметно различающийся performance в зависимости от версии .NET Runtime.
VD>Ну, а что ты хочешь?
Очевидно, чтобы такого не было.
VD>При переходе с 1.х на 2.х проблема хватало.
Достаточно много кода мигрировал с 1 на 2, потом на 3/3.5, подобного особо не замечал.
При переходе на 2+ был профит по производительности, когда не параметризованный код впоследствии переписывался на параметризованный, т.к. заметно сокращалось кол-во операций boxing/unboxing-а.
VD>И при переходе с 2.х на 4.х тоже. Вы еще очень легко отделались, если это единственная проблема при переносе.
Пока перевел небольшой проект только ради возможности удобно распараллелить (Parallel LINQ) обработку достаточно больших массивов текстовых данных, чисто для экономии своего времени, пока других сюрпризов между runtime-м 2.0 и 4.0 не заметил, проект простой и судить особо не о чем.
VD>Я как раз внимательно все прочел. И в названии темы String.IndexOf не присутствует. Название вон сверху.
В root-овом сообщении присутствует:
http://rsdn.org/forum/dotnet/7731686.1
Автор: 4058
Дата: 16.05.20
Дата: 16.05.20
VD> ... Ну. одна функция стала по медленнее. Никакого отношения к производительности самого дотнета это не имеет. Производительность зависит от кучи фаторов. И главное это работа компилятора (джит, нген) и сборщика мусора.
В данном случае эта функция использовалась часто, никто не говорит про .NET в целом, речь конкретно про String.IndexOf и заметно различающийся performance в зависимости от версии .NET Runtime.
VD>Ну, а что ты хочешь?
Очевидно, чтобы такого не было.
VD>При переходе с 1.х на 2.х проблема хватало.
Достаточно много кода мигрировал с 1 на 2, потом на 3/3.5, подобного особо не замечал.
При переходе на 2+ был профит по производительности, когда не параметризованный код впоследствии переписывался на параметризованный, т.к. заметно сокращалось кол-во операций boxing/unboxing-а.
VD>И при переходе с 2.х на 4.х тоже. Вы еще очень легко отделались, если это единственная проблема при переносе.
Пока перевел небольшой проект только ради возможности удобно распараллелить (Parallel LINQ) обработку достаточно больших массивов текстовых данных, чисто для экономии своего времени, пока других сюрпризов между runtime-м 2.0 и 4.0 не заметил, проект простой и судить особо не о чем.
Re[4]: Регресс производительности при переходе с FW 3.5 SP1
Здравствуйте, VladD2, Вы писали:
VD>Я как раз внимательно все прочел. И в названии темы String.IndexOf не присутствует. Название вон сверху.
В root-овом сообщении присутствует:
http://rsdn.org/forum/dotnet/7731686.1
VD> ... Ну. одна функция стала по медленнее. Никакого отношения к производительности самого дотнета это не имеет. Производительность зависит от кучи фаторов. И главное это работа компилятора (джит, нген) и сборщика мусора.
В данном случае эта функция использовалась часто, никто не говорит про .NET в целом, речь конкретно про String.IndexOf и заметно различающийся performance в зависимости от версии .NET Runtime.
VD>Ну, а что ты хочешь?
Очевидно, чтобы такого не было.
VD>При переходе с 1.х на 2.х проблема хватало.
Достаточно много кода мигрировал с 1 на 2, потом на 3/3.5, подобного особо не замечал.
VD>И при переходе с 2.х на 4.х тоже. Вы еще очень легко отделались, если это единственная проблема при переносе.
Пока перевел небольшой проект только ради возможности удобно распараллелить (Parallel LINQ) обработку достаточно больших массивов текстовых данных, чисто для экономии своего времени, пока других сюрпризов между runtime-м 2.0 и 4.0 не заметил, проект простой и судить особо не о чем.
VD>Я как раз внимательно все прочел. И в названии темы String.IndexOf не присутствует. Название вон сверху.
В root-овом сообщении присутствует:
http://rsdn.org/forum/dotnet/7731686.1
Автор: 4058
Дата: 16.05.20
Дата: 16.05.20
VD> ... Ну. одна функция стала по медленнее. Никакого отношения к производительности самого дотнета это не имеет. Производительность зависит от кучи фаторов. И главное это работа компилятора (джит, нген) и сборщика мусора.
В данном случае эта функция использовалась часто, никто не говорит про .NET в целом, речь конкретно про String.IndexOf и заметно различающийся performance в зависимости от версии .NET Runtime.
VD>Ну, а что ты хочешь?
Очевидно, чтобы такого не было.
VD>При переходе с 1.х на 2.х проблема хватало.
Достаточно много кода мигрировал с 1 на 2, потом на 3/3.5, подобного особо не замечал.
VD>И при переходе с 2.х на 4.х тоже. Вы еще очень легко отделались, если это единственная проблема при переносе.
Пока перевел небольшой проект только ради возможности удобно распараллелить (Parallel LINQ) обработку достаточно больших массивов текстовых данных, чисто для экономии своего времени, пока других сюрпризов между runtime-м 2.0 и 4.0 не заметил, проект простой и судить особо не о чем.