Сообщение Re[9]: C# vs Dart - перспективы от 28.08.2023 8:24
Изменено 28.08.2023 8:35 Alekzander
Re[9]: C# vs Dart - перспективы
Здравствуйте, Философ, Вы писали:
A>>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Ф>Я прогонял. Много, часто, упорно и долго этим занимался. У меня в профайлере были разные приложения, в т.ч. с кастомным layout'ом и местами с кастомной отрисовкой. В т.ч. я сам и выделял регионы, и рисовал через GDI, и битмапы через BitBlt гонял. Так что я тебе точно скажу что там тормозит: в половине случаев там тормозит обсчёт layut'а, в трети случаев кастомная отрисовка, а ещё в четверти стандартные контролы слишкмо часто рисуются.
Ф>И я тебе точно скажу, что компиляция имеет смысл. Более того, имеет смысл включение оптимизации при компиляции: тормоза в дебажной сборке — не страшно, а в релизной тормозить уже не должно.
Это две разные компиляции. Вот что он написал:
>мы будем в рантайме парсить HTML
Можно скомпилировать HTML, чтобы парсить в рантайме не приходилось. Чтобы вместо этого была тупо десериализация DOM. А ты говоришь, судя по "имеет смысл включение оптимизации при компиляции", о том, чтобы вообще выкинуть декларативное описание и заменить его 100% императивным кодом. Ты на этом, конечно, сможешь что-то выиграть, но только ценой снижения скорости разработки, причём очень высокой (если разрабатывать что-то более-менее сложное). Это как отказаться от SQL и самому писать в файлы ДЛЯ ОПТИМИЗАЦИИ — где-то прокатит, но чтобы такие размены обсуждать, надо сначала пописать деларативные гуи, чтобы было с чем сравнивать.
A>>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Ф>Я прогонял. Много, часто, упорно и долго этим занимался. У меня в профайлере были разные приложения, в т.ч. с кастомным layout'ом и местами с кастомной отрисовкой. В т.ч. я сам и выделял регионы, и рисовал через GDI, и битмапы через BitBlt гонял. Так что я тебе точно скажу что там тормозит: в половине случаев там тормозит обсчёт layut'а, в трети случаев кастомная отрисовка, а ещё в четверти стандартные контролы слишкмо часто рисуются.
Ф>И я тебе точно скажу, что компиляция имеет смысл. Более того, имеет смысл включение оптимизации при компиляции: тормоза в дебажной сборке — не страшно, а в релизной тормозить уже не должно.
Это две разные компиляции. Вот что он написал:
>мы будем в рантайме парсить HTML
Можно скомпилировать HTML, чтобы парсить в рантайме не приходилось. Чтобы вместо этого была тупо десериализация DOM. А ты говоришь, судя по "имеет смысл включение оптимизации при компиляции", о том, чтобы вообще выкинуть декларативное описание и заменить его 100% императивным кодом. Ты на этом, конечно, сможешь что-то выиграть, но только ценой снижения скорости разработки, причём очень высокой (если разрабатывать что-то более-менее сложное). Это как отказаться от SQL и самому писать в файлы ДЛЯ ОПТИМИЗАЦИИ — где-то прокатит, но чтобы такие размены обсуждать, надо сначала пописать деларативные гуи, чтобы было с чем сравнивать.
Re[9]: C# vs Dart - перспективы
Здравствуйте, Философ, Вы писали:
A>>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Ф>Я прогонял. Много, часто, упорно и долго этим занимался. У меня в профайлере были разные приложения, в т.ч. с кастомным layout'ом и местами с кастомной отрисовкой. В т.ч. я сам и выделял регионы, и рисовал через GDI, и битмапы через BitBlt гонял. Так что я тебе точно скажу что там тормозит: в половине случаев там тормозит обсчёт layut'а, в трети случаев кастомная отрисовка, а ещё в четверти стандартные контролы слишкмо часто рисуются.
Ф>И я тебе точно скажу, что компиляция имеет смысл. Более того, имеет смысл включение оптимизации при компиляции: тормоза в дебажной сборке — не страшно, а в релизной тормозить уже не должно.
Это две разные компиляции. Вот что он написал:
>мы будем в рантайме парсить HTML
Можно скомпилировать HTML, чтобы парсить в рантайме не приходилось. Чтобы вместо этого была тупо десериализация DOM. А ты говоришь, судя по "имеет смысл включение оптимизации при компиляции", о том, чтобы вообще выкинуть декларативное описание и заменить его 100% императивным кодом. Ты на этом, конечно, сможешь что-то выиграть, но только ценой снижения скорости разработки, причём очень высокой ценой (если разрабатывать что-то более-менее сложное). Это как отказаться от SQL и самому писать в файлы ДЛЯ ОПТИМИЗАЦИИ — где-то прокатит, но чтобы такие размены обсуждать, надо сначала пописать декларативные гуи, чтобы было с чем сравнивать.
A>>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Ф>Я прогонял. Много, часто, упорно и долго этим занимался. У меня в профайлере были разные приложения, в т.ч. с кастомным layout'ом и местами с кастомной отрисовкой. В т.ч. я сам и выделял регионы, и рисовал через GDI, и битмапы через BitBlt гонял. Так что я тебе точно скажу что там тормозит: в половине случаев там тормозит обсчёт layut'а, в трети случаев кастомная отрисовка, а ещё в четверти стандартные контролы слишкмо часто рисуются.
Ф>И я тебе точно скажу, что компиляция имеет смысл. Более того, имеет смысл включение оптимизации при компиляции: тормоза в дебажной сборке — не страшно, а в релизной тормозить уже не должно.
Это две разные компиляции. Вот что он написал:
>мы будем в рантайме парсить HTML
Можно скомпилировать HTML, чтобы парсить в рантайме не приходилось. Чтобы вместо этого была тупо десериализация DOM. А ты говоришь, судя по "имеет смысл включение оптимизации при компиляции", о том, чтобы вообще выкинуть декларативное описание и заменить его 100% императивным кодом. Ты на этом, конечно, сможешь что-то выиграть, но только ценой снижения скорости разработки, причём очень высокой ценой (если разрабатывать что-то более-менее сложное). Это как отказаться от SQL и самому писать в файлы ДЛЯ ОПТИМИЗАЦИИ — где-то прокатит, но чтобы такие размены обсуждать, надо сначала пописать декларативные гуи, чтобы было с чем сравнивать.