Сообщение Re[2]: Регресс производительности при переходе с FW 3.5 SP1 от 16.05.2020 15:32
Изменено 16.05.2020 15:33 4058
Re[2]: Регресс производительности при переходе с FW 3.5 SP1 на FW 4+ (String.Ind
Здравствуйте, Serginio1, Вы писали:
S>Ща .Net Core 3.1 и там говорят скорость выше. Кроме того можно еще попробовать .Net Native из UWP
Обновил VS 2019 до версии 16.5.5, сбилдил и запустил этот "тест" под Core 3.1 — результат аналогичен Core 2.1.
offtop:
Как это можно понимать, более 10-ка лет .NET FW "нашпиговывают" множеством сомнительных плюшек в плане повседневной практичности, при этом местами "отламывают" такую важную вещь для повседневности как производительность, причем в самых неожиданных местах.
Можно понять, когда в 2.0 мы получили параметризованные типы и анонимные делегаты, в 3.0 лямбда-выражения, это все было реально нужно, библиотеки и языки органично развивались по большей части в правильном направлении.
Конечно для обработки "офисных" документов (PDF/Excel/Word), различных конвертеров, компрессии, драйверов к различным БД, криптографии/ЭЦП, да и много другого приходится "тащить" сторонние библиотеки (т.к. либо чего-то просто нет, либо есть — но очень плохо), но я не замечал при постепенном переходе от 1.0 до 3.5 SP1 потери производительности ранее написанного кода.
В расчет не берем средства разработки, которые все меньше задумывались о трате ресурсов.
Ну а говорить про то, как безобразно выжирают вычислительный ресурс JavaScript (который уже лет 10 пытаются воткнуть везде где ему совсем не место) и прочие Python-ы даже не стоит.
S>Ща .Net Core 3.1 и там говорят скорость выше. Кроме того можно еще попробовать .Net Native из UWP
Обновил VS 2019 до версии 16.5.5, сбилдил и запустил этот "тест" под Core 3.1 — результат аналогичен Core 2.1.
offtop:
Как это можно понимать, более 10-ка лет .NET FW "нашпиговывают" множеством сомнительных плюшек в плане повседневной практичности, при этом местами "отламывают" такую важную вещь для повседневности как производительность, причем в самых неожиданных местах.
Можно понять, когда в 2.0 мы получили параметризованные типы и анонимные делегаты, в 3.0 лямбда-выражения, это все было реально нужно, библиотеки и языки органично развивались по большей части в правильном направлении.
Конечно для обработки "офисных" документов (PDF/Excel/Word), различных конвертеров, компрессии, драйверов к различным БД, криптографии/ЭЦП, да и много другого приходится "тащить" сторонние библиотеки (т.к. либо чего-то просто нет, либо есть — но очень плохо), но я не замечал при постепенном переходе от 1.0 до 3.5 SP1 потери производительности ранее написанного кода.
В расчет не берем средства разработки, которые все меньше задумывались о трате ресурсов.
Ну а говорить про то, как безобразно выжирают вычислительный ресурс JavaScript (который уже лет 10 пытаются воткнуть везде где ему совсем не место) и прочие Python-ы даже не стоит.
Re[2]: Регресс производительности при переходе с FW 3.5 SP1
Здравствуйте, Serginio1, Вы писали:
S>Ща .Net Core 3.1 и там говорят скорость выше. Кроме того можно еще попробовать .Net Native из UWP
Обновил VS 2019 до версии 16.5.5, сбилдил и запустил этот "тест" под Core 3.1 — результат аналогичен Core 2.1.
offtop:
Как это можно понимать, более 10-ка лет .NET FW "нашпиговывают" множеством сомнительных плюшек в плане повседневной практичности, при этом местами "отламывают" такую важную для повседневности вещь как производительность, причем в самых неожиданных местах.
Можно понять, когда в 2.0 мы получили параметризованные типы и анонимные делегаты, в 3.0 лямбда-выражения, это все было реально нужно, библиотеки и языки органично развивались по большей части в правильном направлении.
Конечно для обработки "офисных" документов (PDF/Excel/Word), различных конвертеров, компрессии, драйверов к различным БД, криптографии/ЭЦП, да и много другого приходится "тащить" сторонние библиотеки (т.к. либо чего-то просто нет, либо есть — но очень плохо), но я не замечал при постепенном переходе от 1.0 до 3.5 SP1 потери производительности ранее написанного кода.
В расчет не берем средства разработки, которые все меньше задумывались о трате ресурсов.
Ну а говорить про то, как безобразно выжирают вычислительный ресурс JavaScript (который уже лет 10 пытаются воткнуть везде где ему совсем не место) и прочие Python-ы даже не стоит.
S>Ща .Net Core 3.1 и там говорят скорость выше. Кроме того можно еще попробовать .Net Native из UWP
Обновил VS 2019 до версии 16.5.5, сбилдил и запустил этот "тест" под Core 3.1 — результат аналогичен Core 2.1.
offtop:
Как это можно понимать, более 10-ка лет .NET FW "нашпиговывают" множеством сомнительных плюшек в плане повседневной практичности, при этом местами "отламывают" такую важную для повседневности вещь как производительность, причем в самых неожиданных местах.
Можно понять, когда в 2.0 мы получили параметризованные типы и анонимные делегаты, в 3.0 лямбда-выражения, это все было реально нужно, библиотеки и языки органично развивались по большей части в правильном направлении.
Конечно для обработки "офисных" документов (PDF/Excel/Word), различных конвертеров, компрессии, драйверов к различным БД, криптографии/ЭЦП, да и много другого приходится "тащить" сторонние библиотеки (т.к. либо чего-то просто нет, либо есть — но очень плохо), но я не замечал при постепенном переходе от 1.0 до 3.5 SP1 потери производительности ранее написанного кода.
В расчет не берем средства разработки, которые все меньше задумывались о трате ресурсов.
Ну а говорить про то, как безобразно выжирают вычислительный ресурс JavaScript (который уже лет 10 пытаются воткнуть везде где ему совсем не место) и прочие Python-ы даже не стоит.