Поскольку XAML компилируется, разницы в выполнении такого кода быть не должно. Winforms (например, код):
Form formPeter = new Form();
Textbox textbox = new Textbox();
Label l1 = new Label1();
Xaml не анализируется во время выполнения, как я думал ... :-)
Но как насчет рендеринга / выполнения больших форм с большим количеством элементов управления? Какая технология быстрее?





WPF использует DirectX для рендеринга (который намного быстрее) вместо собственного Windows GDI.
Как вы, возможно, уже знаете, Native GDI основан на растровых изображениях. Поскольку WPF является векторным, WPF может использовать аппаратную поддержку гораздо лучше, чем GDI.
Однако решение о выборе WPF или Winforms в значительной степени зависит также от других факторов - гибкости, которая вам нужна в пользовательском интерфейсе, сколько носителей поддерживает ваше приложение и т. д. WPF не является заменой Winforms - и это не серебро пуля для всех проблем.
С появлением большего количества функций аппаратного ускорения WPF может работать намного лучше, чем ваши приложения Winform.
Несколько интересных блогов я прочитал раньше.
Какая технология быстрее? Боюсь, на ваш вопрос нет простого ответа.
Ваш комментарий о том, что XAML не анализируется во время выполнения, является как истинным, так и ложным. Хотя XAML не анализируется, его нормализованная двоичная версия (встроенная в качестве ресурса в ваше приложение), называемая BAML является, анализируется во время выполнения. Сказать, что DirectX быстрее, чем GDI, также является чем-то вроде упрощения - технологии рендеринга на основе WPF и GDI просто имеют характеристики производительности разные. Например, WPF использует сохраненный режим рендеринга, тогда как WinForms и другие технологии на основе GDI этого не делают. Объекты WPF, как правило, намного тяжелее, потому что они поддерживают намного больше свойств, чем их аналоги winforms. У нас есть десятилетия знаний о том, как заставить GDI работать довольно быстро, и относительно короткое время с WPF и XAML.
WPF достаточно быстр для написания приложений, но вам нужно постоянно следить за тем, чтобы количество ваших элементов не увеличивалось (например, путем создания слишком сложных шаблонов, а затем их повторения сотни или тысячи раз в вашем пользовательском интерфейсе). Кроме того, WPF по-разному работает на разном графическом оборудовании (поскольку он обращается к DirectX изнутри). 2D-контент должен хорошо работать в WPF, даже если он полностью отображается в программном обеспечении (скажем, как это было бы на виртуальной машине), но для анимированного, сглаженного 3D с большим количеством элементов требуется реальная мощность графического процессора. По мере того, как время идет, и графическое оборудование становится все более мощным и распространенным, а знания о том, как настраивать производительность WPF, улучшаются, мы должны увидеть, как WPF продвигается вперед (при условии, что сейчас это немного так ... для некоторых сценариев ... иногда). Так что, я думаю, ответ - «это зависит от обстоятельств».
Мне любопытно и немного пессимистично оценивать производительность терминального сервера.
Как и должно быть, Гуге. WPF отправляет графику, а не примитивные команды или токены, представляющие элементы управления. AFAIK, Microsoft также не взяла на себя никаких мер для исправления этой ситуации.
Рисование в WPF выполняется намного быстрее, но объекты тяжелее. Если кинуть 1000 отдельных кнопок, будет ползать. С другой стороны, эти кнопки могут иметь сложную прозрачность и градиенты без значительного снижения производительности.
Производительность WPF и Winforms больше не является основным критерием.
Я знаю, что этот вопрос задавался раньше, но с учетом .NET 4.x и улучшений, которые привели к повышению производительности WPF, думает ли сообщество, что производительность больше не является критерием выбора одной технологии над другой.
В целом настольные приложения WPF работают значительно лучше, чем эквивалентный код WinForms, в сценариях, требующих сложного пользовательского интерфейса, настройки стилей и сценариев с интенсивным использованием графики, благодаря нескольким архитектурным преимуществам WPF над WinForms:
Однако оба работают достаточно быстро, поэтому я не думаю, что производительность будет большой причиной выбора WPF вместо WinForms. Это будет возможность быстрее создавать лучшие приложения.
Разработчики игр и другие, кому нужна максимальная производительность, не будут использовать WPF или WinForms для критических частей своего пользовательского интерфейса: они будут программировать на Direct3D или даже на оборудовании.
эта статья описывает платформы (UWP, WPF и Windows Forms) и помогает вам определить лучшую из них для вашего приложения.
Для модульного тестирования Winforms первое, что вы должны сделать, - это убедиться, что у вас есть надлежащее отделение бизнес-логики от формы. В основном, используя шаблон MVC. Затем вы можете легко протестировать все, что находится за пределами формы, как если бы формы даже не существовало.
Я бы сказал, что объекты WPF, как правило, легче из-за разреженной инфраструктуры хранения WPF. Значения свойств зависимостей сохраняются только в том случае, если они отличаются от значения по умолчанию, поэтому достигается огромная экономия памяти.