Compartilhar via

WF3 Design Time Performance - II

  • Artigo

Recently, we worked with one of the customers whose designer launch was painfully slow. The project was a medium sized one and hence the performance degradation was particularly baffling.

To figure out what's wrong, I did an Attach to Process(to debug) with another VS instance to the VS with the workflow designer and turned on all the exceptions. Next, I tried to launch the workflow designer and Whoa…

I am getting hundreds of File IO Not Found Exceptions. No wonder the performance was slow.

I tried compilation of the project to check if the customer is missing something. No, nothing was wrong. The project built successfully. What was happening that directly contributed to the slow designer performance?

The problem is:

If an activity used in a workflow is dependent on Assembly A(uses some types out of A) and Assembly A is dependent on Assembly B; during design time, when you load the workflow, the object instance of each activity in the workflow is created. During this instance creation, CLR wants to ensure that not only the activity assembly, but all its dependent assemblies are loaded(A and B) as well. For this purpose, the VS Type Resolution Service goes through the path where it finds the activity assembly, to look for A and B. It also finally looks up GAC.

If it still doesn't find the assemblies in those paths, then it will do an Assembly.Load for A and B with their partial names. This would mean that if an assembly with Version 1.0.0.0 is not found it will try 1.0.0.1. Similarly, if assembly with culture = neutral is not found, then look for assembly with a specific windows or framework culture. This continues with different variations based on the CLR algorithms for loading assemblies with partial names till they are found. Thus you can imagine the number of File-Not-Founds per assembly and then think about the same with multiple assemblies that are needed and not being found during the workflow design time authoring environment.

Hence, in addition to the tips we talked about in the previous post, please do an Attach To Process to the workflow designer VS instance and see if you have too many File Not Found Exceptions. If so, please ensure the necessary assemblies are in the VS probe path(possibly assembly references in the workflow project or adding to VS(devenv.exe) probe paths) and see if that improves the performance drastically.

In my next post, we will talk about what if none of the solutions we have discussed till date works. Stay tuned!

Thanks,

Kushal.

Comments

  • Anonymous
    July 26, 2010
    Cool, Kushal, I have one question: Does the WF 4.0 allow also to call one piece of workflow from a workflow?