I am reviewing a rather large Windows Workflow Foundation .xaml file.
I am finding several nested Sequence activities.
Example:
Note: This is a simplistic example to help illustrate my question.
Main Sequence
Query Data SequenceWrite CSV SequenceThere query data sequence would contain activities related to setting variables and querying a data source.
The write to CSV Sequence contains activities related to setting variables and writing a CSV file.
The two child activities serve no other purpose then to logically organize activities.
The .xaml file I am reviewing is quite large and complex.
Are there negative performance affects building a workflow with several nested activities?
Yes there are negetive performance issues with nested activities. The reason for this is that the workflow instance is run on a single thread in both activities. The WF runtime schedules work on that thread using a queue-like structure. When the activity executes, it simply schedules its child activities with the runtime. Because the activities do blocking, synchronous work, they block the thread the workflow is running on.
Workflow state machine transitions in and out of deeply nested states are more expensive due to activity tree navigation and AEC cloning. You should try to avoid having deeply nested states as much as possible.
The activity instance state is automatically managed by the workflow runtime through the Activity Execution Context (AEC). The workflow runtime uses the AEC to maintain activity instance state and to run compensation logic when required.
When an activity needs to be re-executed, a new AEC is created using the BinaryFormatter class. This operation can have a performance impact on your workflow application, especially in cases where the AEC being cloned is complex (for example, when there are multiple nested activities).
The solution is to run the workflow asynchronously using WorkflowApplication object.