WF3 design performance I

Translation: http://blogs.msdn.com/kushals/archive/2010/04/05/wf3-design-time-performance-i.aspx

Before we begin to discuss the performance of WF3 design, let's clarify some terms.

1. WF3 is used. net framework3.0 and 3.5 are released, although WF3 also serves. net Framework 4.0, but system. workflow. * The Assembly is its latest version.
2. wf4 was first released as part of. NET Framework 4.0. system. Activities. * is its latest version.

Yes. WF3 and wf4 are both released in. NET Framework 4.0.

We have heard a lot about the performance during design. In general, complaints are that the performance of the designer degrades exponentially as the number of activities increases.

In the following articles, we will discuss how to improve the performance of the designer and some patches we have made to improve the performance. Here is a white paper on Workflow Performance.

Below are some tips to remember:
1. Transfer the types used in the workflow to a different project
Transfers interfaces, event types, custom activities, and helper classes to different projects. For example, there is a customer solution and 10 projects, each of the 10 workflows has a corresponding event type. In this way, the type information of the updated design will be re-parsed every time the user changes the workflow. Transferring these event types to a different set of programs helps improve performance.

2. Reduce the number of workflows in a project
Each workflow is a type, whether in the form of C #/VB code or xoml. They all need to parse and generate the corresponding design-time type. Therefore, if there are 10 workflows in a project, we need to parse all other workflows when opening any workflow for the first time. We can add two or three workflows to a project by function grouping to improve performance.

3. refactor large state machine workflows and small
One example is that a customer finds that a workflow has 780 states and 1000 activities, resulting in 16000 lines of code in initializecomponent. Refactoring a state machine workflow into a small reusable workflow can improve performance and reduce a large number of redundant states.

4. Do not perform long tasks in the active constructor.
The constructor of an activity is called during design, so things like connecting to a database should never be placed in the constructor, which will lead to a long time for the designer to open these activities.

Of course, the above four points will not solve the performance problems of all your designers. Please pay attention to the subsequent articles on this topic.