locked
Designer performance of Sequence vs. Flowchart RRS feed

  • Question

  • I have a workflow that I modeled first using a flowchart style control, then have switched over to a sequence with embedded if / sequences.  It's not large by any stretch - but the performance of just simply loading up the flowchart beats the sequence hands down.  Opening with flowchart is approx. 15-20 seconds vs. 10 minutes and running for the sequence.  Is this a known design style that one should try to use flowchart when possible?  My architecture is as follows:

    1. WF's are stored in a database
    2. Using a rehoster to open them from the database
    3. Custom activities are stored in a different project than the rehoster project [although the activities share the project with quite a bit of code - it isn't a dedicated project to only the activities]

    I tried opening the workflow in visual studio and it just hangs.  The rehoster isn't much better.
    The workflow has the following structure:

    Sequence
    + If
    ++ (Then) Sequence
    +++ Zero Out Reserves [custom]
    +++ Close Tasks [custom]
    +++ Activity Placeholder [custom]
    + If
    ++  (Then) Sequence
    +++ Create task [custom]
    +++ Create task [custom]
    +++ Create task [custom]
    +++ Create task [custom]
    +++ If
    ++++ (Then) Sequence
    +++++ Create task [custom]
    +++++ Create task [custom]
    + If
    ++ (Then) Sequence
    +++ Activity Placeholder [custom]
    +++ Create Task [custom]
    +++ Activity Placeholder [custom]
    +++ If
    ++++ (Then) Sequence
    +++++ Create task [custom]
    +++++ Create task [custom] 

    It seems the further down I try to scroll the more it hangs.  Eventually it hijacks the entire machine by drawing either a pure black or pure white window [with pretty aero border] over both monitors and will not allow me to switch focus to anything else.  I am on a dual core windows 7 machine with 8 gig of memory, so it isn't starved for resources.  

    The custom tasks have the graphical components as follows:
    1. Zero out reserves - TextBlock
    2. Close Tasks - TextBlock
    3. Activity Placeholder - 1 TextBox
    4. Create Task - 6 Labels, 4 CheckBoxes, 5 ComboBoxes, 5 ExpressionTextBoxes, 1 TextBox

    Thoughts?



    Tuesday, April 19, 2011 8:16 PM

Answers

  • I've seen very similar performance characteristics to what you describe. My observations were,

    • A sequence only gets slow when you have nesting of some description: if, nested sequences, for / while loops etc.
    • This can be mitigated by collapsing these activities in the designer - the two arrows in top right of the activity collapse it. This appears to not have to draw / validate all the child activities so is quicker.
    • Prefer the use of Flowcharts where ever possible. It seems like a sign that the logic you modeling is better suited to a flow chart when the designer gets too slow to use.
    • Turn of automatic validation by default. In my rehosted designer, I set the reg key HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\v4.0.0.0\System.Activities.Presentation\DisableValidateOnModelItemChanged = 1 on startup and then validate using ActivityValidationServices.Validate() before save / on user button click.

    Still we get designer lockups occasionally, but it is mostly usable. The Workflow we have at the moment are about 160Kb of raw Xaml.

    • Marked as answer by John Hennesey Wednesday, April 20, 2011 3:26 PM
    Wednesday, April 20, 2011 10:01 AM
  • WOW!!!!  what an incredible difference.  It went from killing it after 15 minutes to completely loaded in < 2 seconds.  The problem was I didn't have the registry entry, which I was expecting to already be there [I figured the workflow designer would create it while the clickonce was running].  

    Thank you!

    • Marked as answer by John Hennesey Thursday, April 21, 2011 7:51 PM
    Thursday, April 21, 2011 7:51 PM
  • Another suggestion to anyone who stumbles upon this...

    I also default to always collapsing all activities upon opening a workflow.  This seems to make it faster too.  The code:

    var designerView = _workflowDesigner.Context.Services.GetService<DesignerView>();
    designerView.ShouldCollapseAll = true;
    
    
    

    Friday, June 3, 2011 7:09 PM

All replies

  • I've seen very similar performance characteristics to what you describe. My observations were,

    • A sequence only gets slow when you have nesting of some description: if, nested sequences, for / while loops etc.
    • This can be mitigated by collapsing these activities in the designer - the two arrows in top right of the activity collapse it. This appears to not have to draw / validate all the child activities so is quicker.
    • Prefer the use of Flowcharts where ever possible. It seems like a sign that the logic you modeling is better suited to a flow chart when the designer gets too slow to use.
    • Turn of automatic validation by default. In my rehosted designer, I set the reg key HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\v4.0.0.0\System.Activities.Presentation\DisableValidateOnModelItemChanged = 1 on startup and then validate using ActivityValidationServices.Validate() before save / on user button click.

    Still we get designer lockups occasionally, but it is mostly usable. The Workflow we have at the moment are about 160Kb of raw Xaml.

    • Marked as answer by John Hennesey Wednesday, April 20, 2011 3:26 PM
    Wednesday, April 20, 2011 10:01 AM
  • Thank you very much - very good suggestions.  I am using the designer as a clickonce application available only online, so it doesn't store stuff in the registry in that location... I'm off on the hunt to figure out where (if) it stores it and will post back later for the next person.
    Wednesday, April 20, 2011 3:28 PM
  • Thank you very much - very good suggestions.  I am using the designer as a clickonce application available only online, so it doesn't store stuff in the registry in that location... I'm off on the hunt to figure out where (if) it stores it and will post back later for the next person.



    We deliver our designer as a ClickOnce application and it seems to work find for us. When the main rehosted designer window opens, we set the registry key to 1 and then set it to 0 when the windows closes.

    Hope it helps

    George

    Thursday, April 21, 2011 2:45 PM
  • Is your application set to only be available online, or does it go through an installation process (and is available offline via the start menu)
    Thursday, April 21, 2011 2:56 PM
  • Its online only. It connects to a WCF service to do its work so we just use it online only
    Thursday, April 21, 2011 3:59 PM
  • WOW!!!!  what an incredible difference.  It went from killing it after 15 minutes to completely loaded in < 2 seconds.  The problem was I didn't have the registry entry, which I was expecting to already be there [I figured the workflow designer would create it while the clickonce was running].  

    Thank you!

    • Marked as answer by John Hennesey Thursday, April 21, 2011 7:51 PM
    Thursday, April 21, 2011 7:51 PM
  • Another suggestion to anyone who stumbles upon this...

    I also default to always collapsing all activities upon opening a workflow.  This seems to make it faster too.  The code:

    var designerView = _workflowDesigner.Context.Services.GetService<DesignerView>();
    designerView.ShouldCollapseAll = true;
    
    
    

    Friday, June 3, 2011 7:09 PM
  • I have got one question I am writing an app that stores workflows, whether they are finished or not

    But when I load the workflow from the database I did not get an of the errors  with that workflow if the work flow had errors

    How did you get round that problem mine was to save the xaml to a file and then load.

    Wednesday, July 13, 2011 7:41 PM
  • When you say "stores workflows" do you mean it stores the workflow definition, or the instance data, or both?  I have minimal experience with Wf 3.x, but I believe a big difference between the two is you have to store the wf definition when persisting - when an instance is persisted it stores only the data (via persistance store) - it is up to you to save off the definition.

    Also "whether they are finished or not" - please elaborate.  If a workflow errors out it will go into a persistableIdle state [provided you are using a persistance store].  Are you saying you interrupt it and attempt to persist while it is running?  

    Wednesday, July 13, 2011 9:07 PM