다음을 통해 공유

Workflow Designer and performance

  • 아티클

// we improved WF designer performance in .NET 3.5 sp1 , After .NET 3.5 sp1 also, you may see some designer performance problems, you can follow these guide lines to increase WF designer performance

Commonly reported issues

1. Time taken to open a workflow document is long.

2. Opening Activity bind dialog is slow.

Reasons for slow down

The Workflow designer relies on parsing the source code in the current project to provide updated design information in workflow design surface, rules dialog intellisense etc. This is mainly to enable scenarios where picking up changes from the source even before the project has been rebuilt.

Tips to make designer perform better

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.

REFERENCE:

  https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3808068&SiteID=1

Comments