WF3 Design Time Performance - I

Before, we start talking about the WF3 design time performance, let me clarify some of the terminologies:

1. WF3 is the version of Workflow shipped as part of .NET Framework 3.0 and 3.5. Note that WF3 is also shipped as part of .NET Framework 4.0. Meaning, System.Workflow.* assemblies are shipped as part of the latest version of the framework.

2. WF4 is the latest version of Workflows we are shipping first time as part of .NET Framework 4.0. Meaning, System.Activities.* assemblies are shipped for first time in the latest version of framework as well.

Yes, both the versions of WF3 and WF4 are being shipped simultaneously in .NET Framework 4.0.

Now, about the design time performance, yes, we have heard you about the performance issues. In general, the complaint is that the performance of the designers starts decreasing exponentially as the number of activities on the designer starts increasing.

The next few articles, we will talk about how you can improve the performance of the designers as well as see some fixes that we have done to improve the performance.

To start with, one of the white papers about the general Workflow performance has been published in here.

A few other tips to keep in mind to improve the Design Time performance are(initially published in a forum post by Lorenz Prem and Ramraj B):

1. 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.

2. 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.

3. 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.

4. 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.

Of course, there will be scenarios where the above 4 tips wont solve all/any of your issues with the designer performance. For that, please stay plugged-in for the next few blog posts on this topic:-)

Thanks,

Kushal.