Почему тот же код в WPF работает медленнее, чем в Windows Forms? - PullRequest
3 голосов
/ 13 апреля 2010

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

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

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

Для выполнения кода в Windows Forms требуется 5968 мс - 6024 мс, а в WPF - 6953 мс.

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

Ответы [ 5 ]

3 голосов
/ 13 апреля 2010

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

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

3 голосов
/ 13 апреля 2010

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

2 голосов
/ 13 апреля 2010

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

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

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

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

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

1 голос
/ 15 апреля 2010

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

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

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

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

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

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

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

1 голос
/ 13 апреля 2010

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

...