(WF4,WF3) Workflow Performance Talk

  • Article

Today I had the pleasure of attending a brownbag (read ‘lunchtime presentation’) by Dustin Metzgar from the WF Performance team. He ran us through a slide deck with a lot of interesting performance comparisons between WF3 and WF4. Workflow Foundation 4.0 really is faster than Workflow Foundation 3.0 in a large variety of scenarios. For a technical discussion you can read about it in the WF4 performance white paper on MSDN.

The most impressive performance gain in WF4 over WF3 is in raw runtime performance. You can see this at the top of the whitepaper, and it looks like this, note the logarithmic scale.

Performance Test Data Graph

In terms of activity execution, WF4 is 100 times or more faster than WF3 across a wide range of scenarios, that’s 10,000% faster! Now I think everyone would be super-excited if WF4 offered that performance gain across the board. However, activity execution is just one part of the story. There are a lot of other WF features that most people will use before, after, and in-between activity executionthat have effects on overall performance. Some of the big ones:

-Workflow runtime creation, and CacheMetadata()
-Tracking
-Persistance to SQL store

CacheMetadata and Persistance are two of the most costly parts of the whole workflow lifecycle, and so this means that in real-world scenarios the performance gains are still significant (I don’t have a handy number to quote), but much more modest.

Now you don’t always have to pay all those performance costs for every workflow, and it’s worth finding out more about why, which ones you can void, and how.

The other really interesting fact I learned about workflow performance that I did not know is Fast-Pathing. It turns out, and this shocked me, that a VisualBasicExpression activity is usually faster to execute than the equivalent CodeActivity. When I heard this I thought ‘that makes no sense’, but as Dustin explained, there is actually code in the framework that recognizes the VisualBasicExpression and LambdaExpression classes and treats them specially by doing less work. End result, they can run faster than a code activity that performs the same computation.

Hopefully I can find and post some more information about this later, in the meantime, if you haven’t been there yet, you might like to visit the archive of Dustin’s Workflow-related posts and performance tips here:

https://blogs.msdn.com/b/dmetzgar/archive/tags/wf/

Thanks Dustin!