locked
Windows Workflow very slow in Debug Mode RRS feed

  • Question

  • Hi,

    I am using Visual Studio 2012. When I run my workflow app with "Start Debugging", it is very slow compared to normal C# code.

    I made a proof of concept Workflow App that did this basic thing:

    1. Argument: List of 10,000 integers

    2. Variables: StartDate, EndDate, data

    3. Workflow:

    a. Using Assign Activity: StartDate = DateTime.Now

    b. Using ForEach Activity for each item in List of 10,000 integers

         - Using Assign Activity: data = data + item

    c. Using Assign Activity: EndDate = DateTime.Now

    d. Using WriteLine Activity: "WF Foreach: " + argInput.Count.ToString() + " items took this long: " + EndDate.Subtract(StartDate).TotalMilliseconds.ToString()


    When I run in Visual Studio 2012 using "Start Debugging", this simple workflow takes 1.29 minutes to run.

    When I run using regular C# code, this logic runs 48 milliseconds.

    When I run with "Start Without Debugging", it takes 48 milliseconds.

    What is wrong with Visual Studio? Are there any settings I need to do to fix this?



    Appreciate any help I can get.

    Thanks!





    • Edited by TDCua Monday, March 9, 2015 1:54 PM
    Tuesday, March 3, 2015 9:05 PM

Answers

  • TDCua,

    There is a fair amount of work done by the Workflow Runtime to enable the Visual Studio debugger
    to deal with breakpoints within the Workflow Designer.

    The workflow runtime is a "state machine" that keeps track of which activity is currently
    executing, along with Variable values, etc. Visual Studio expects a functional/hierarchical structure.
    The workflow runtime constructs a "virtual call stack of activities" that isn't the "real stack".
    It is a simulation of a real stack. The same is true for Variables, etc.

    When a workflow starts executing, the runtime checks to see if there is a debugger attached and
    does work to intitialize various data structures (instrumentation) for this stack simulation.

    Then, each time an activity begins execution and completes execution, a bunch of work is done to
    ensure that the VS debugger has the correct information regarding Variable values, line numbers, etc.

    The bottom line is that a trade off was made to allow debugging XAML-based workflows using the
    WorkflowDesigner easier, rather than performant. What you are experiencing is By Design.

    If you wrote the same workflow entirely in code rather than XAML, it runs much faster under the
    debugger. But writing workflows in code instead of using the designer and generating XAML is
    much harder to do.

    In .Net 4.5 and beyond, the instrumentation work that is done to the workflow that allows debugging
    to be done using the Workflow Designer is triggered by the existence of a specific Attached Property
    in the XAML file. It looks something like this:

    <sads:DebugSymbol.Symbol>d05FOlxUZW1wUHJvamVjdHNcV....</sads:DebugSymbol.Symbol>

    If you opened up the XAML file with an XML debugger (or use "View Code" from the Solution Explorer)
    and commented out this line of code, then the workflow runtime will NOT instrument the activities
    for debugging and the debugging will NOT be possible with the Workflow Designer. But the workflow will
    run lots faster in the debugger.

    BUT, every time you modify the workflow definition in the Workflow Designer and save it, a new
    DebugSymbol attached property will be generated and included in the XAML and you will be back to
    square 1.

    Jim

    • Marked as answer by Angie Xu Thursday, March 19, 2015 1:06 PM
    Wednesday, March 18, 2015 12:06 AM

All replies

  • Try set the performance to aplications
    http://www.win2012workstation.com/applications-performance/
    Tuesday, March 3, 2015 9:32 PM
  • Try set the performance to aplications
    http://www.win2012workstation.com/applications-performance/

    My performance is set to Programs by default.
    Tuesday, March 3, 2015 9:41 PM
  • TDCua,

    There is a fair amount of work done by the Workflow Runtime to enable the Visual Studio debugger
    to deal with breakpoints within the Workflow Designer.

    The workflow runtime is a "state machine" that keeps track of which activity is currently
    executing, along with Variable values, etc. Visual Studio expects a functional/hierarchical structure.
    The workflow runtime constructs a "virtual call stack of activities" that isn't the "real stack".
    It is a simulation of a real stack. The same is true for Variables, etc.

    When a workflow starts executing, the runtime checks to see if there is a debugger attached and
    does work to intitialize various data structures (instrumentation) for this stack simulation.

    Then, each time an activity begins execution and completes execution, a bunch of work is done to
    ensure that the VS debugger has the correct information regarding Variable values, line numbers, etc.

    The bottom line is that a trade off was made to allow debugging XAML-based workflows using the
    WorkflowDesigner easier, rather than performant. What you are experiencing is By Design.

    If you wrote the same workflow entirely in code rather than XAML, it runs much faster under the
    debugger. But writing workflows in code instead of using the designer and generating XAML is
    much harder to do.

    In .Net 4.5 and beyond, the instrumentation work that is done to the workflow that allows debugging
    to be done using the Workflow Designer is triggered by the existence of a specific Attached Property
    in the XAML file. It looks something like this:

    <sads:DebugSymbol.Symbol>d05FOlxUZW1wUHJvamVjdHNcV....</sads:DebugSymbol.Symbol>

    If you opened up the XAML file with an XML debugger (or use "View Code" from the Solution Explorer)
    and commented out this line of code, then the workflow runtime will NOT instrument the activities
    for debugging and the debugging will NOT be possible with the Workflow Designer. But the workflow will
    run lots faster in the debugger.

    BUT, every time you modify the workflow definition in the Workflow Designer and save it, a new
    DebugSymbol attached property will be generated and included in the XAML and you will be back to
    square 1.

    Jim

    • Marked as answer by Angie Xu Thursday, March 19, 2015 1:06 PM
    Wednesday, March 18, 2015 12:06 AM