locked
Performance difference between designer created workflow and a workflow created manually in code RRS feed

  • Question

  • I am just beginning to use WF4 so I created a workflow using the designer. Basically, it creates and assigns a couple variables. When I have a while loop making sure that one of the variables is less than 1000. In the while loop, I increment the counter variable by 1. Finally, outside of the while loop, I WriteLine the value. Then using WorkflowInvoker.Invoke(new Workflow1()).

    This workflow takes 16-20 seconds to run.

    I then created the same workflow in code (e.g. new Sequence { ... new Assign { ... }, new While { ... } }).

    This workflow takes under 1/10 of a second.

    Is this expected behavior that designer created workflows are magnitudes slower than coded workflows? For a background, this is all inside of a test console application.

    Thanks in advance,

    Justin

    Tuesday, June 29, 2010 3:14 PM

Answers

  • OK, I figured it out. The problem wasn't a WF runtime problem. The problem was that the VS2010 debugger w/ Intellitrace turned on hurts the performance of designer based workflows much more than code created workflows. If I run the test application outside of the debugger they run with the same performance characteristics. If I run the test application within the debugger, but with Intellitrace turned off, the XAML workflow is slower but only by one order of magnitude.
    • Marked as answer by jb90 Tuesday, June 29, 2010 6:03 PM
    Tuesday, June 29, 2010 6:02 PM

All replies

  • There should not be a difference in the execution performance of a workflow based upon how it was created.

    However, a workflow that is being deserialized from XAML might show some larger startup cost around deserialization versus a workflow that is created programmatically.

    I can't say much more without actually seeing your two workflows - there may be other differences in them. If you want to post both workflows, I am sure someone can take a look at it.

    Tuesday, June 29, 2010 3:19 PM
  • I will try and get the two workflows uploaded later today. I thought that the XAML deserialization may be costly. To try and eliminate this, one of the variables I added to the workflow was a Stopwatch. At the beginning, just prior to entering the While activity, I assign it the value Stopwatch.StartNew(). Then immediately after the while loop, I assign to another variable the ElapsedMilliseconds of the Stopwatch variable. There was a small amount of XAML deserialization and WorkflowInvoker overhead, all but about .5 seconds was spent in the While loop.

    This information is background, hopefully I can upload the sample later.

    Tuesday, June 29, 2010 4:37 PM
  • OK, I figured it out. The problem wasn't a WF runtime problem. The problem was that the VS2010 debugger w/ Intellitrace turned on hurts the performance of designer based workflows much more than code created workflows. If I run the test application outside of the debugger they run with the same performance characteristics. If I run the test application within the debugger, but with Intellitrace turned off, the XAML workflow is slower but only by one order of magnitude.
    • Marked as answer by jb90 Tuesday, June 29, 2010 6:03 PM
    Tuesday, June 29, 2010 6:02 PM