I've got a WF State Machine which I use to handle page navigation on a WPF Media Center App. It's got a half-dozen states which each have Initialization handlers and one or two EventDriven handlers.
When you first make a StateMachine workflow using a VS template, you have the option of using a code-behind model, or a code-separate model wherein the workflow topology is described in a .Xoml (xml) file.
Lately, whenever I'm working with the State Machine, Visual studio intermittently hangs for up to ten seconds, after which it always recovers.
Might this be a problem inherent in the Xoml parsing that will go away if I redo the state machine using the Code-behind model?
Anyone have relevant experience regarding Workflow Designer performance in either model?
Best Answer
This is a well known problem with the workflow designer in visual studio 2008. We were promised improvements in sp1 (and supposedly got them, but I have noticed nothing). Suggestions include:
Move all types used in workflows to a different project than where the workflows live.
Move interfaces, event types, custom activities, helper classes to a different project than in which the workflow resides. E.g. in the solution from a customer, there were about 10 project, with 10 workflows each and 10 associated event types. These types are all reparsed to update to build the design time type information every time the user changes workflows in the project. Moving these to a different assembly e.g just one project with all the types needed for the 10 workflow projects will help improve performance.
Reduce the number of workflows in a project.
Each workflow is a type ( directly in c#/vb, and indirectly in xoml case) that needs a design time type to be built by parsing, so if there are 10 workfows in a project, opening any workflow in the project for the first time means parsing all the other workflows as well. Classifying these workflows based on their function and grouping them in 2-3 workflows per project improved performance drastically.
Re-Factor large state machine workflows into smaller workflows
One example we found from a customer had 780 states and 1000 activity binds in the same workflow, leading to a InitializeComponent() of about 16000 lines. Factoring this state machine into smaller reusable workflows will making designer performance much better, and reduce a lot of redundant states.
Don’t do long running work in activity constructors
Activity constructors are called during design time also, so doing things like connecting to a database etc should never be done in constructors, this can make the designer take too long to open workflow documents using these activities.
From: http://blogs.msdn.com/madhuponduru/archive/2008/09/30/workflow-designer-and-performance.aspx
-Oisin