Comments 45
50%-ное ускорение запуска
А можно делать приложения, у которых нет никакого "времени запуска"? Или 4-гигагерцевые 8-ядерные процессоры такое не потянут?
Такое не тянут смузихлебы-программисты
ну зачем же вы так в флэшбэки
Да, не сложно. Полностью без следа удалить антивирус и отключить проверку прав доступа к файлам. Большая часть времени загрузки моих приложений - это ожидание отклика на std::open_file(), причём параллелить их почти бесполезно.
у меня в винде 10 висит процесс calculator в состоянии "приостановлено". Если его прибить - через несколько секунд он появится снова. И даже при этом запускается он не мгновенно. Куда уж там "фото" которому еще и диски почитать надо. (эх... 256 мб для винХп)...
Уделите капельку времени настройке своей операционной системы.
Спасибо. Это было любопытно. Отдельное "спасибо" мелкомягким за: Select Start , then select Settings > Privacy > Background apps. Я бы в жизни не догадался, что в разделе Privacy могут скрываться приложения, которые запускаются в фоновом режиме. проверю еще как это на скорость запуска повлияло, но без ребута ничего пока не поменялось.Как висело в фоне, так и висит.
[soulcry]И вообще как я должен был догадаться, что оно где-то есть? винда же изкаропки работает![/soulcry]
Нельзя. Приложение не может стартовать мгновенно. Даже хелловорд на ассемблере стартует не мгновенно, а сначала загрузится с накопителя в оперативную память, затем ещё сколько-то миллисекунд будет запускаться.
4-гигагерцевые 8-ядерные процессоры такое не потянут?
В теории да, на практике любая подсистема в сотый-тысячный раз копирует метры таблиц и релокейтов и заново проводит инициализацию.
Когда уже динамические либы станут реально динамическими?
Лучше бы винду элевен оптимизировали
Оптимизировали-оптимизировали, а потом выходят новости вида https://habr.com/ru/news/841848/ "Приложение «Фото» в Windows будет работать в фоновом режиме для более быстрого запуска"
И так сойдёт
Оно и так уже давно реализовано. Винда постоянно кеширует в свободной ОЗУ наиболее популярные приложения.
И точно так же давно реализована настройка, которая отключает фоновую работу современных приложений.
Похоже на анекдот с покупкой козы, но на ИТ рельсах: сначала сделаем в 10 раз медленее; потом это ускорим в полтора раза. И вот уже все довольны: ускорение же есть.
Такой подход работает, если вариантов нет, и народ постепенно начинает "жрать кактус".
В случае с Майками они по-моему теряют долю компьютеров и дождутся, что с их оси народ поуползает на какой-нибудь макось или линукс.
сначала сделаем в 10 раз медленее; потом это ускорим в полтора раза.
Первое что пришло в голову при прочтении новости :-) Ошеломительный рост производительности, ничего не скажешь. Ну и запуск приложения «Фото» в фоновом режиме, ради того чтобы оно не открывалось вечность – те еще костыли.
В случае с Майками они по-моему теряют долю компьютеров и дождутся, что с их оси народ поуползает на какой-нибудь макось или линукс.
Первый раз я это слышал лет 25-30 назад, ща выйдет OS/2 и Винде капец.
Есть решение, но не всем понравится, вместо костылей и оберток через браузер, писать нативно, как раньше, прирост скорости и снижение потребления ресурсов, на 1000000000% гарантирован
Всё есть файл браузер.
А удобство разработки у такого решения есть:]?
Ещё какое! Если взять C#, то у него очень развитые инструменты, очень большое коммьюнити, гигантское количество библиотек.
Если считаете, что IL - это недостаточно нативно, то существует Native AOT.
Native AOT не поддерживает Windows приложений (WPF и WinForms).
Есть котлин мультиплатформ, который поддерживает AOT и на котором очень комфортно писать.
Вроде бы еще дарт поддерживает AOT и по отзывам норм писать на нем.
Честно говоря никогда не пробовал. У меня не было задачи сделать шарп быстрее, он и так достаточно хорош. Но я знаю, что AvaloniaUI поддерживает Native AOT.
Если взять C#, то у него очень развитые инструменты, очень большое коммьюнити, гигантское количество библиотек.
C# это всего-навсего язык программирования общего назначения (кстати, очень хороший). Для создания UI нужна специальная подсистема (WinForms или WPF).
WinForms это обёртка над морально устаревшим WinAPI, помноженная на чудовищные архитектурные ошибки (декларативное описание UI сериализуется в императивный код — это просто пушка!).
А WPF тормозит ничуть не хуже, чем браузер. Потому что XAML это и есть HTML, только лишённый Фатального Недостатка. И, конечно, ни с чем не совместимый. Так, что сравнивать размер комьюнити и количество библиотек под HTML и WPF просто смешно. Вдобавок, Майкрософт может пристрелить его как сервелат, или перевести в режим Шрёдингера (ни жив, ни мёртв).
XAML это не HTML. Он выглядит, как HTML, но это компилируемый язык со всеми вытекающими. Вообще странно их сравнивать. XAML это не только разметка, но и биндинги.
Для создания UI нужна специальная подсистема (WinForms или WPF)
UWP, MAUI. Есть кроссплатформенная AvaloniaUI, которая, кстати, умеет в AOT. Авалония НЕ работает с нативным API, а рисует сама. Есть экзотика вроде Qt/.NET или ImGui.NET.
Есть Unity и Godot для игр. Есть OpenTK для работы с OpenGL/CL.
декларативное описание UI сериализуется в императивный код
Не понял пассажа. Когда у винформс было декларативное описание?
XAML это не HTML. Он выглядит, как HTML, но это компилируемый язык со всеми вытекающими
Компилируется в BAML, который при загрузке должен снова парситься и интерпретироваться wpf-движком, чтобы создать в памяти Visual Tree. На сериализации в бинарник вместо текста экономим гроши.
Вообще странно их сравнивать. XAML это не только разметка, но и биндинги
Если js/html-фреймворки с биндингами. Но тяжеловесность xaml в его потрясающих возможностях. Можно стилизовать любую часть любого компонента, стилизовать межкомпонентное пространство (listview с вертикальной и горизонтальной прокруткой это один и тот же listview, но по-разному стилизованный, а можно и вообще навесить свой контейнер компонент в форме пирамидки, никто не запрещает). Плюс всякие анимации и рендер внутри рендера (сложнейший шаблон можно объявить отдельной сущностью и заставить сжиматься/крутиться в анимациях по таймеру). Всё это не бесплатно.
Не меньше возможностей, чем у современного CSS
Есть кроссплатформенная AvaloniaUI
Нет wysiwyg-дизайнера в Visual Studio, а разработка UI в стиле "поправил-скомпилировал-запустил-увидел что контрол всё ещё торчит на 3 пикселя левее чем хочется-повторил" очень утомительна.
Когда у винформс было декларативное описание?
Разработчики WinForms не код пишут, а контролы перетаскивают мышкой с тулбаров и меняют им свойства в редактилках. Соответственно, представление формы в IDE - это и есть первичное, с чем работают. При сохранении это уже сериализуется в императивный код, при загрузке снова парсится - кринж.
Всё это не бесплатно.
Не меньше возможностей, чем у современного CSS
Не находите, что где-то здесь находится корреляция? Тормозить оно может, тормозить может что угодно вообще. Зависит от того, как это использовать. Возвращаясь к теме нативности, замл намного ближе к железу, чем HTML. И работает быстрее на тех же задачах. Хотя бы в силу компилированности в рантайме и прямой связке с языком. Впрочем, я не хотел бы, чтобы спор упирался в замл. У того же дотнета есть и веб-решения. Классический разор и фактически стриминговый блазор.
Я говорил про C#. На нём можно писать близко к железу, причём с небывалым удобством. Change my mind.
Нет wysiwyg-дизайнера в Visual Studio
Скрытый текст
Разработчики WinForms не код пишут, а контролы перетаскивают мышкой с тулбаров и меняют им свойства в редактилках
Я забыл предупредить, я с винформс уже как 15 лет работаю ) Там да, есть привычка в визуальном редакторе редактировать. Но это не имеет никакого отношения к декларативности.
При сохранении это уже сериализуется в императивный код, при загрузке снова парсится - кринж.
Никуда оно не парсится при загрузке. Оно один раз компилируется в исполняемый код и всё. Дальше выполняется. И не ясно, что для вас кринж. Что wysiwyg в конечном итоге превращается в набор команд? А как иначе может быть?
А как иначе может быть?
Сериализация в любой формат разметки. xml или dfm или даже ресурсы диалогов в стиле Win32.
Есть соблазн написать в коде
#if DEBUG
this.button1.Text = "NOT OK";
#else
this.button1.Text = "OK";
#endif
А потом непонятно, как оно откроется в редакторе и переживёт ли пересохранение.
Сериализация в любой формат разметки. xml или dfm или даже ресурсы диалогов в стиле Win32.
XAML - это подвид XML. Дальше что процессору делать с этим XML?
А потом непонятно
Мне понятно. Даже понятно, переживёт или нет. Во всех *.designer.cs большими буквами написано "ничего не пхать сюдой - перезапишется"
XAML - это подвид XML. Дальше что процессору делать с этим XML?
Что и всегда - парсить и интерпретировать. Если хочется это сделать в compile-time, можно при компиляции сгенерить этот код, не включая в исходники. Хранить разметку в виде кода, и декомпилировать перед каждым редактированием - странная идея.
Странные выводы. Вся ветка про то, что надо делать нативные приложения вместо кучи обёрток в виде электрона и интерпретируемого HTML (тоже подвид XML). Я вот и напомнил про компилируемый язык. А вы предлагаете пойти по пути электрона - опять использовать интерпретацию.
Хранить разметку в виде кода, и декомпилировать перед каждым редактированием - странная идея.
Во-первых это работает. Во вторых не обязательно в винформс упираться. Есть axaml, например, на который я очень толсто намекаю. Там хранится модель разметки, а при компиляции приложения из модели генерируется код.
Как у разработчика, у меня нет никаких претензий к WPF. Там при желании можно сделать быстро и удобно. Или понять, что сделать правильно - слишком сложно и мириться с этим уже осознанно.
Но как пользователь, я вижу, что большие приложения на WPF такие же тормозные, как на электроне. Потому что очень легко наворотить неоптимальных решений, полировать их до идеала в промышленной разработке никто не будет.
До HiDPI дисплеев основная претензия к WPF была по рендерингу - чтобы формы не выглядели "мыльно", нужно было специально их дизайнить (правильно использовать SnapToDevicePixels, что для массовых разработчиков - не эстэтов было непонятной дичью). С 4к экранами вопрос решился.
Насчёт WinForms в принципе ничего не имею против. Там выше комментатор написал, что такая сериализация - кривая. Я пояснил, почему.
приложения на WPF такие же тормозные, как на электроне
Да кто же виноват в вашей выборке? ) Посмотрите вот на моё поделие, там правда не впф, а авалония. Но всё равно замл. Работает с такими объёмами данных и с такой скоростью, какие просто невозможны на электроне.
Пути назад нет, они даже тёмную тему не портировали на нативный Win32 интерфейс.
Телеметрия в каждом компоненте из коробки уже ничего не кушает?
Microsoft пообещала «невероятный прирост производительности» современных приложений Windows 11
На i9:)
Microsoft пообещала «невероятный прирост производительности» современных приложений Windows 11 на современном i9-99999K
Это не единственная проблема. Как отметили некоторые пользователи, приложения WinAppSDK медленно работают. Поскольку они в значительной степени зависят от Microsoft Edge WebView, то используют больше оперативной памяти.
Теперь Microsoft готовит исправление.
Хорошая попытка, Майкрософт, но нет.
Нужен будет HTML/кроссплатформа, я возьму CEF или Sciter.
Нужно будет крохотное и быстрое приложение, я напишу на голом WinAPI, которое ты будешь поддерживать вечно. (Не будешь — тебе же хуже).
Для чего мне на ровном месте вляпываться в твои вендор-локи?
Сократили время загрузки на 50% - напишем, что приложения станут на 50% быстрее.
Microsoft пообещала «невероятный прирост производительности» современных приложений Windows 11