GotSpeech.NET

OK, I've seen many questions around how to design speech applications and how to share information around a speech application.  I'm summarizing my approach.  Please respond if you think this method if faulty or a better method is available.  So far, it seems to be the easier.

I create a single workflow "MainWorkFlow".  All shared members exist as properties of this workflow.

Example:

private String userID = "";

public String UserID
{
   get { return userID }
   set { userID = value; }
}

All other "sub-workflows" are created as speech sequence activities.  They appear as items in the Toolbox after compiling.  These speech sequence activities set and get the UserID property from the main workflow.

How to access from a "sub-workflow" Example:

((MainWorkFlow)Workflow).UserID = "A1";

Hi Martial,

Thanks a lot ..

I really appreciate all your help.

Sounds alright Martial but one caveat - nesting the "subflows" too deep can cause huge performance issues. I got into this mess once and now I don't nest more that to deep (i.e. Main==>SublfowA==>SubflowB).

---

Marshall Harrison
Microsoft MVP, Office Communications Server


www.GoldSys.com
W: 303.447.2774
H: 904.342-6205

the gotspeech guy

I have noticed a significant problem in debug mode, but don't see the issue during an actual call.  I mostly go 3 levels deep although there are 1 or 2 that go 4 levels.

This is an issue with the way MSS clones the workflows but I'm not sure where the magic number is.

If I do something like this now then the only time I go to the 3rd level is for a Disconnect. Rather that include extra logic to go back to the main and do a disconnect I just use a "subflow" for disconnect that handles all the necessary logging and cleanup.

---

Marshall Harrison
Microsoft MVP, Office Communications Server


www.GoldSys.com
W: 303.447.2774
H: 904.342-6205

the gotspeech guy

Am I wrong in believing these shared properties should be of type: InstanceDependencyProperty?

Just as an additional recommendation, I have a library project for my Activities in which I define an interface that they expect the Workflow to implement (the interface defines the properties that the workflow needs to make available).  Then I access the properties like so:

User u = ((IWorkflowInterface)Workflow).User;

Not a big difference, but a little less tightly coupled.

Marshall,

As you know, I'm trying to build up a picture of what causes these huge performance issues that you have experienced.  When I look at the problem of deep cloning, I don't see it being limited to SpeechSequence since IfElse and While also do cloning.  From the data I have from Brian Carlson on the "Long Compile Times" thread, he has close to 1,000 activities and is not experiencing a long compile time, but is experiencing a significant 1st-call delay (he doesn't specify about subsequent calls).  I also have a copy of your original "10 minute compile" application and that has 2,300 activities.

My feeling about this issue is that the relevant factor is how many activities in total there are in the workflow, not so much how deeply nested the SpeechSequences are.  Lets compare:

1. a workflow with an ifElse containing 5 branches, each with a SpeechSequence containing 200 child activities.
2. a workflow with 5 nested ifElse activities, such that the left branch of each ifElse contains a single activity, and the right branch is a SpeechSequence containing 200 activities culminating in the nested SpeechSequence.

For both workflows, there is a total of ~1,000 activities.

For (1) all 1,000 activities will be cloned when the workflow starts, then again by the ifElse, but when executing a particular SpeechSequence, only 200 activities will be cloned.  If each branch of the ifElse is visited in turn, you have 3,000 clones in total.

For (2), as with (1), there will be 1,000 clones when the workflow starts and, for the top-level ifElse, there will be another 1,000 clones.  Then we differ; the top-level SpeechSequence will clone 1,000 again, it's nested ifElse and SpeechSequence will clone 800 each, etc, to give a total cloning of 2,000+2,000+1,600+1,200+800+400 = 8,000 clones in total.

And that's assuming that there are no further cloning activities in those 1,000 (unlikely).

 

I've hijacked this thread too long.  Suffice to say that nesting is a problem, but it's not the depth per-se, rather how many activities are contained within.  Based on Brian's data, it looks like 1,000 activities within a single SpeechSequentialWorkflow is too many.  Maybe 500 is a reasonable upper limit, beyond which the workflow should be broken up into multiple SpeechSequentialWorkflows?

 

Martial - you report that you haven't experienced problems.  What size workflows are you using? Please respond to this thread: http://gotspeech.net/forums/thread/7198.aspx.

 

---

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Yikes!  I must be generating 1000's of clones.  How do you count clones?  So what gets cloned in a speech workflow, every object?  Then every object again within an ifElse branch.

We've definately been having some issues lately with opening the design screen and running the debugger.  I don't see any performance issues yet when running the live system.  I don't really know how to count everything since I have about 40 speechSequence activities and many get called several times.  I'm not every sure about depth.  I'm sure some areas go at least 7 levels deep.