Почему тот же самый код в WPF работает медленнее, чем в Windows Forms?

Question

Я сделал кучу тестов с фреймворком 4.0 и старше, и я не понимаю, почему тот же код работает медленнее при использовании WPF по сравнению с Windows Forms:

Это код, он не имеет ничего общего с пользовательским интерфейсом элементы:

 Random rnd = new Random(845038); 
     Int64 number = 0; 
     for (int i = 0; i < 500000000; i++) 
     { 
      number += rnd.Next(); 
     } 

код занимает 5968ms - 6024ms для выполнения в Windows Forms и 6953ms в WPF.

Вот сообщение с загружаемым раствором: http://blog.bettiolo.it/2010/04/benchmark-of-net-framework-40.html

Answer 1

Когда я загрузил zip-файл и посмотрел на ваш код, проблема стала очевидной: Это не тот же код.

Поскольку два теста имеют разный код, они компилируются по-разному с помощью компилятора C# и оптимизируются JIT-компилятором. Для локальных переменных назначаются разные регистры. Используются различные методы вызова. Используются разные смещения стека.

Вот несколько отличий я отмечал между двумя эталонными методами:

1. Они принимают различные типы параметров
2. Они содержат различное число (9 против 7) и типов локальных переменных
3. Они делают разные номера вызовов методов
4. У них разное количество петель
5. Один вызов Application.DoEvents(), а другой не

Я полагаю, что в вашей версии кода WinForms компилятор JIT разместил переменную i в смещении стека, тогда как в версии WPF она поместила ее в регистр, который затем необходимо сохранить на каждом итерация.

В любом случае, не стоит винить разницу в WPF и WinForms: обвинять разницу в наличии двух разных тестов, которые выглядят внешне похожими, но оптимизированы по-разному.

Разбить код тестирования на статический метод в отдельном классе. Если вы используете идентичный код в обоих тестах, я могу в значительной степени гарантировать вам, что вы получите одинаковые результаты.

Answer 2

Многое может произойти в течение шести секунд на машине Windows. Я бы предположил, что фоновая обработка, которая имеет место в WPF, немного отличается (и несет немного больше служебных данных), чем то, что происходит в Winforms.

Answer 3

У вас есть какая-то форма, показывающая на экране? Я думаю, что накладные расходы для формы могут быть тем, что вы видите.

Answer 4

Первый цикл работает с той же скоростью для меня.

Вы измеряете без отладчик прилагается?

Answer 5

Прежде всего, чтобы исключить какие-либо факторы окружающей среды, вы должны были бы запустить этот тест для каждого решения в течение 24-48 часов. Во-вторых, ошибочная логика его медленности. Если вы отделите какой-либо gui-gode от этого приложения, вы увидите, что оба они нацелены на одну и ту же платформу ergo, они не должны быть разными.

Если вы тестируете, какая инфраструктура графического интерфейса работает быстрее, ваш тест недействителен, так как он не играет ни с сильными, ни с слабыми сторонами. Для тестирования WPF в Winforms таким образом необходимо упустить фундаментальные различия между обеими структурами.

Существует не предвзятый способ тестирования каждой структуры, поскольку оба они существуют. Сказать, что WPF работает быстрее с точки зрения предоставления сложных примитивов или дорогостоящих графических интерфейсов, является ошибочным, поскольку тест будет смещен в WPF.

Тот факт, что базовая модель может быть настолько разной, означает, что любое тестирование такого характера было бы субъективным. Я не доверяю испытаниям такого характера просто потому, что они либо пытаются доказать точку зрения авторов, либо опровергнуть чужие методы.

Я бы не стал беспокоиться о скорости просто потому, что если у клиента есть возможность правильно запускать приложение WPF, то выгоды или промахи будут настолько незначительными, что они не будут иметь значения.