Сообщение Re[2]: Регресс производительности при переходе с FW 3.5 SP1 от 16.05.2020 16:36
Изменено 16.05.2020 16:43 4058
Re[2]: Регресс производительности при переходе с FW 3.5 SP1
Здравствуйте, rameel, Вы писали:
R>Здравствуйте, 4058, Вы писали:
4>>Доброго времени суток.
4>>Краткое предисловие:
4>>В процессе переноса кода с FW 3.5 SP1 на FW 4+, заметил на некоторых фрагментах существенную просадку производительности.
4>>Проблема выявилась в неожиданном месте, а именно на строковых операциях наподобие String.IndexOf, которые данный код активно использует.
R>Все дело в используемой версии таблицы Unicode. В версии .NET3.5 использовался Unicode 5.0, c 4 — Unicode 5.1, с NET4.5 — Unicode 6.0 и далее, в .NET Core зависит от ОС.
Интересно почему тогда string.Contains дает аналогичные результаты на 3.5 и 4+, может локале-ориентированный компаратор сильно "фонит":
Также аналогичные результаты можно получить, если явно в качестве компаратора указать StringComparison.Ordinal:
P.S. В данном примере я
R>Здравствуйте, 4058, Вы писали:
4>>Доброго времени суток.
4>>Краткое предисловие:
4>>В процессе переноса кода с FW 3.5 SP1 на FW 4+, заметил на некоторых фрагментах существенную просадку производительности.
4>>Проблема выявилась в неожиданном месте, а именно на строковых операциях наподобие String.IndexOf, которые данный код активно использует.
R>Все дело в используемой версии таблицы Unicode. В версии .NET3.5 использовался Unicode 5.0, c 4 — Unicode 5.1, с NET4.5 — Unicode 6.0 и далее, в .NET Core зависит от ОС.
Интересно почему тогда string.Contains дает аналогичные результаты на 3.5 и 4+, может локале-ориентированный компаратор сильно "фонит":
c += arr.Count(s => s.Contains(key));3.5: String (100000) 1000000 op / 0.248 sec = 4030540
4.0: String (100000) 1000000 op / 0,237 sec = 4205221Также аналогичные результаты можно получить, если явно в качестве компаратора указать StringComparison.Ordinal:
c += arr.Count(s => s.IndexOf(key, StringComparison.Ordinal) > -1);3.5: String (100000) 1000000 op / 0,246 sec = 4053168
4.0: String (100000) 1000000 op / 0,239 sec = 4181658P.S. В данном примере я
Re[2]: Регресс производительности при переходе с FW 3.5 SP1
Здравствуйте, rameel, Вы писали:
R>Здравствуйте, 4058, Вы писали:
4>>Доброго времени суток.
4>>Краткое предисловие:
4>>В процессе переноса кода с FW 3.5 SP1 на FW 4+, заметил на некоторых фрагментах существенную просадку производительности.
4>>Проблема выявилась в неожиданном месте, а именно на строковых операциях наподобие String.IndexOf, которые данный код активно использует.
R>Все дело в используемой версии таблицы Unicode. В версии .NET3.5 использовался Unicode 5.0, c 4 — Unicode 5.1, с NET4.5 — Unicode 6.0 и далее, в .NET Core зависит от ОС.
Интересно почему тогда string.Contains дает аналогичные результаты на 3.5 и 4+, может локале-ориентированный компаратор сильно "фонит":
Также аналогичные результаты можно получить, если явно в качестве компаратора указать StringComparison.Ordinal:
R>Здравствуйте, 4058, Вы писали:
4>>Доброго времени суток.
4>>Краткое предисловие:
4>>В процессе переноса кода с FW 3.5 SP1 на FW 4+, заметил на некоторых фрагментах существенную просадку производительности.
4>>Проблема выявилась в неожиданном месте, а именно на строковых операциях наподобие String.IndexOf, которые данный код активно использует.
R>Все дело в используемой версии таблицы Unicode. В версии .NET3.5 использовался Unicode 5.0, c 4 — Unicode 5.1, с NET4.5 — Unicode 6.0 и далее, в .NET Core зависит от ОС.
Интересно почему тогда string.Contains дает аналогичные результаты на 3.5 и 4+, может локале-ориентированный компаратор сильно "фонит":
c += arr.Count(s => s.Contains(key));3.5: String (100000) 1000000 op / 0.248 sec = 4030540
4.0: String (100000) 1000000 op / 0,237 sec = 4205221Также аналогичные результаты можно получить, если явно в качестве компаратора указать StringComparison.Ordinal:
c += arr.Count(s => s.IndexOf(key, StringComparison.Ordinal) > -1);3.5: String (100000) 1000000 op / 0,246 sec = 4053168
4.0: String (100000) 1000000 op / 0,239 sec = 4181658