I am trying to understand
We have something like...
public class BusinessRule
{
public DynamicActivity Activity { get; private set; }
public BusinessRule(string ruleSetAsXaml)
{
Stream stream = new MemoryStream(ASCIIEncoding.Default.GetBytes(ruleSetAsXaml));
this.Activity = ActivityXamlServices.Load(stream) as DynamicActivity;
}
public void Execute(data objData)
{
Dictionary<string, object> inArgs = new Dictionary<string, object>();
inArgs.Add("data", objData);
if (this.Activity != null)
{
WorkflowInvoker invoker = new WorkflowInvoker(this.Activity);
outArgs = invoker.Invoke(inArgs);
}
}
}
And we have many business rules like this. The xamls are stored in database, all these rules are instantiated once and kept in a collection (in memory). These get called when required (with additional arguments) using Execute() method.
Now my question...Is there anyway I can make WorkflowInvoker.Invoke()
more faster? Currently it is taking about 00:00:00.1214497
each call with CPU utilization of 25% (on this line) of complete process. It may also be noted that I am not doing anything tricky in xaml.
Am I doing anything wrong here? Do I need to cache meta data?
1)
CacheMetadata is not what you think it is. It is always called prior to execution and is used to build a "representation" of your activity for it to be ready to run. That's also where the validation is made to prevent errors while executing. It's CacheMetadata that is used by the designer to show all those errors you see while visually editing workflows.
CacheMetadata is already optimized not to call certain parts of the build logic on the same workflow instance. Of course it will always be called on each run, mostly because of validation purposes but that's the WF4 nature.
2)
If you're truly caching business rules instances you won't be able to improve that time by much. You're already preventing the XAML parsing/reading which is really the most labor intensive part of the all thing.
If you're using VB expressions on your workflows they've to be compiled, and that takes time. In WF4.5 you can use C# expressions which have to be actively compiled prior to execution, which is a plus. Check more info here. This is really the only thing that comes to my mind right now.