Конструктор рабочих процессов неоправданно медленный. Это Xoml?

Question

У меня есть конечный автомат WF, который я использую для навигации по страницам в приложении WPF Media Center. У него полдюжины состояний, в каждом из которых есть обработчики инициализации и один или два обработчика EventDriven.

При первом создании рабочего процесса StateMachine с использованием шаблона VS у вас есть возможность использовать модель с выделенным кодом или модель с отдельным кодом, в которой топология рабочего процесса описана в файле .Xoml (xml).

В последнее время, когда я работаю с конечным автоматом, Visual Studio периодически зависает до десяти секунд, после чего всегда восстанавливается.

Может ли это быть проблемой, присущей синтаксическому анализу Xoml, которая исчезнет, ​​если я переделаю конечный автомат, используя модель Code-behind?

Кто-нибудь имеет соответствующий опыт относительно производительности Workflow Designer в любой модели?

Answer 1

Это хорошо известная проблема с дизайнером рабочих процессов в visual studio 2008. Нам обещали улучшения в sp1 (и якобы получили их, но я ничего не заметил). Предложения включают в себя:

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

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

Уменьшите количество рабочих процессов в проекте.

Каждый рабочий процесс - это тип (непосредственно в c # / vb, и косвенно в случае xoml), для которого нужен тип времени разработки, который будет создан при синтаксическом анализе, поэтому, если в проекте 10 рабочих процессов, любой рабочий процесс в проекте открывается для первый раз означает анализ всех других рабочих процессов. Классификация этих рабочих процессов на основе их функций и группировка их по 2-3 рабочим процессам на проект позволила значительно повысить производительность.

Рефакторинг рабочих процессов большого конечного автомата в меньшие рабочие процессы

Один пример, который мы нашли у клиента, имел 780 состояний и 1000 привязок активности в одном и том же рабочем процессе, что привело к InitializeComponent () из примерно 16000 строк. Включение этого конечного автомата в меньшие многократно используемые рабочие процессы значительно улучшит производительность дизайнера и сократит множество избыточных состояний.

Не выполняйте длительную работу в конструкторах действий

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

От: http://blogs.msdn.com/madhuponduru/archive/2008/09/30/workflow-designer-and-performance.aspx

-Oisin

Answer 2

VS 2008 дал мне то же самое необычайно медленное поведение, которое вы описываете.

Я работал с тем же проектом WF в VS 2010 (на Win 7 RC VM), и производительность, похоже, значительно улучшилась. По крайней мере, схема не теряется, как в 2008 году.

Так что, может быть, есть надежда на будущее.