Workflow Designer and performance

Question

I am getting somewhat fed up with the performance of the workflow designer and of VS.

 

It uses 60-70% of CPU for 100 seconds or more at a time when trying to display a workflow!

Even just starting to type in to a code file sometimes causes the IDE to hang for 15 seconds or more!

 

firstly, is everyone getting these issues?  or should I look to see if there is something wrong with my PC?

 

It is a 3GHz dual core machine with 2.3GB of RAM

 

the CPU is busy during this time, but I/O is minimal.

 

help, as it reducing productivity and driving me mad!!

 

 

Answer 1

Commonly reported issues

 

1. Time taken to open a workflow document is long.

2. Opening Activity bind dialog is slow.

Reasons for slow down

 

The Workflow designer relies on parsing the source code in the current project to provide updated design information in workflow design surface, rules dialog intellisense etc. This is mainly to enable scenarios where picking up changes from the source even before the project has been rebuilt.

Tips to make designer perform better

1. Move all types used in workflows to a different project than where the workflows live.

 

Move interfaces, event types, custom activities, helper classes to a different project than in which the workflow resides. E.g. in the solution from a customer, there were about 10 project, with 10 workflows each and 10 associated event types. These types are all reparsed to update to build the design time type information every time the user changes workflows in the project. Moving these to a different assembly e.g  just one project with all the types needed for the 10 workflow projects will help improve performance.

 

2. Reduce the number of workflows in a project.

 

Each workflow is a type ( directly in c#/vb, and indirectly in xoml case) that needs a design time type to be built by parsing, so if there are 10 workfows in a project, opening any workflow in the project for the first time means parsing all the other workflows as well.  Classifying these workflows based on their function and grouping them in 2-3 workflows per project improved performance drastically.

 

3. Re-Factor large state machine workflows into smaller workflows

 

One example we found from a customer had 780 states and 1000 activity binds in the same workflow, leading to a InitializeComponent() of about 16000 lines. Factoring this state machine into smaller reusable workflows will  making designer performance much better, and reduce a lot of redundant states.

 

4. Don’t do long running work in activity constructors

 

Activity constructors are called during design time also, so doing things like connecting to a database etc should never be done in constructors, this can make the designer take too long to open workflow documents using these activities.

Answer 2

I now do all of these things.  I have 8 projects in my solution:

 

DAL

BusinessLogic

CustomActivitiesBase

CustomActivities

LocalServices

WorkflowsBase

Workflows

WebUi

 

My state machine workflow (which lives in WorkflowsBase has only about 8 states)

 

Performance is better but still pretty awful (20secs to load the designer, when it loads at all)

 

Answer 3

 

Hi,

 

I'm using Visual Studio 2008 RTM (no beta!!) and Windows Vista x64 Ultimate on a system running AMD x2 4200+ CPU with 4 gigs of RAM.

The performance of the WF designer still is horrible!! It's near at what you can say "unusable".

I think this doesn't bring the hype of WF to the world - it could not go on as this. MS will have to fix some things here.  When I switch from design mode to code it tooks several 10 seconds (~30 secs) - my mouse pointer spins around between hourglass (Vista ring) and normal and I am not able to edit my code. The same issues I discovered with Beta 2. I hoped they'll be fixed in final - but no, nothing fixed. 

 

It takes me about 5 minutes to just change a property of a state activity. Same thing when saving all the WF things, mouse pointer spins around and the IDE is locked up for ~30 seconds. Sometimes when I'd like to display member functions (right dropdown in Code editor) the list is empty (this was already an issue in Beta 2!!!) - it says "Updating ..." - but nothing happens - never.

The Orcas IDE is very great - best thing I've ever seen and worked with - SORRY guys, but this WF designer and its performance is a nightmare!!!

What's your understanding of RTM? Does this mean Beta 3 ?? 

 

Regards

Sven

Answer 4

This reply is really to everyone on this forum experiencing this problem.  I have recently been through extensive performance testing directly with Microsoft over this very issue.  Unfortunately there is no fix available, in fact, according to MS the WF team is considering a future rearchitecting the WF designer to resolve the problem but this will not be any time soon.  The problem today is in the designer and the way it interacts with all of the types in your workflow solutions and projects in that solution AND the sluggishness is directly proportional to the deserialization of workflows (whether xoml based or not); the number of activities in not just the workflow you are loading but all of the workflows in that same project and possibly the solution (depending on how you set up your dependencies), all affecting the speed of deserialization.  In my case we elected to use "compiled" xoml based workflows rather than code based so we experienced sluggishness in loading at runtime also but we fixed most of that problem but turning off validation in the workflow runtime instance.   The application I am working on and supporting uses state machine workflows.  If we had a single state machine workflow for the entire application it would be over 420 states.  We had already planned to keep these in separate workflows according to categories of functionality and we built a hosting mechanism to support transitions from workflow to workflow in a loosely coupled fashion.  So we thought we would be ok.  But as we grouped the workflows into feature sets, one set equals one project in a solution of about 10 projects, we still had sluggishness, as much as 60 or more seconds to load a workflow with only 10 states and 60 activities total in an average WF.  So we were dissapointed and I spent a lot of time reading while doing workflow editing, not fun really and not really productive.  I have since had time to play with hosting the WF designer myself and I believe this will be a temporary solution for us.  When I am hosting the designer many fewer references are seen by the designer because I am controlling the typeprovider loading myself.  The WF designer is pretty good in most of the WFs I need to edit.  I do have a few WFs with about 200 activities (because of the number of rules I need to use) and you can see some sluggishness loading these but editing is relatively smooth.  Samples are available from MS that help you get your own tool working and with the designer there are many possibilities to enhance productivity if you write your own tool.  It is better than start from scratch.  In summary, it is dissappointing about the WF designer performance, there are ways to help but no silver bullet.  I hope this long diatribe helps someone out there in WF land.  Long story short if you want to save time now, reduce the number of activities in your workflows, break up large workflows into smaller units of work if you can.  Also make sure if you have any custom activities that make them as efficient as possible.  Cheers.

Answer 5

Hi tmessina,

 

thanks for the reply. Glad to see that's not only my problem with the very bad performance. But in my case it's only a *very small* workflow - so there should be *no need* for the sluggishness. And by "very small" I mean a state machine workflow with only 12 states. I couldn't imagine what the hell it should be with as many states as you have (several hundreds).

Sorry, but we CANNOT wait until there is another release of WF designer out there (when the WF team will completely redesign it). There should be any workaround or update/patch made be available very soon. It's very annoying when we're all on the WF/WPF/WCF let me say "NETFX 3.0 hype" and the designers and tools are so ugly.

What should I say to my customer: "I'm sorry, but I can't use today's technologies because of the bad performing and behaving designer tools"

BTW: is there any 3rd party designer for WF available? I didn't recognize until now.

 

Please, MS, please fix this tool, we need it!!!

 

While working on my workflow today, I had two times the problem: "VS2008 encountered a problem and needs to close"... very frustrating!

 

Sven

Answer 6

 

I am on the same boat. I have 2 Workfows each with 5 states. One of the states has perhaps 10-15 Activities in a sequence. Any action I take results in a 1 minute wait. Very unproductive.

Answer 7

we are having the same problem. 1state machine with 200states and waiting 5-10min. to get started.
unacceptable

Answer 8

It doesn't seem designer is slow just because of deserialization and type management.

I'm developing a stand-alone IDE based on WF designer. The IDE has integrated facilities to import/export scripts from 3rd party applications. In the case I'm working on right now I'm importing a script that constructs a document; the script is written in an XML file and I'm transforming it back and forth between 3rd party format and xoml using a stylesheet.

I never need to compile this workflow, I only need to edit it and save it back. The activities I made for it are as simple as they get - no constructors or execute methods, yet the problem is there when the imported workflow is big.

I have trouble scrolling through the designer, select items, zoom in and out. The designer nearly freezes, consuming 99% CPU and delivering one frame every 3 seconds - absolutely unacceptable user experience! Those workflows have 500 - 2000

distinct steps; the document that's constructed is about 100 pages and depends on apx 30-90 variables (depending on document type), so the logic is complex.

I'm looking for a way to optimize the ActivityDesigner-s to draw faster. Any clues? 

Answer 9

 

An update from the product team:

We are currently pursuing several ways of improving performance in SP1. These fixes will make the bar move up, but there is still a practical limit to the size of a WF project.

Please use the best practices I outlined in my previous post in this thread. SP1 will increase perf for all your WF projects.

Answer 10

 

SP1? When? Where?

 

 

Thanks

Answer 11

Sharper,

Have you resolved the performance problems you've had with WF?

I've been working on WF performance for a while now, the visual rendering performance in particular.

My take on the problem was to design a stand-alone WF editor, make custom designers for activities and optimize everything I can on the way.

Answer 12

 

Hello,

 

yesterday, final Service Pack 1 for Visual Studio has been released. I didn't check if there is any performance update on WF designer by now. But let's give it a try ...

Answer 13

With SP1, performance is still poor and 'VS2008 needs to close' every time. That's what I call a useless SP.

Answer 14

SP1 has been available for a couple of weeks now. It does include several perf fixes in the WF designer area. Please let us know, if your performance is better with the pack installed.

Note that the SP is not a “cure all” solution for perf. There comes a point where a workflow just gets too large for the available hardware to handle. We are pushing the limits higher with SP1, and future releases. Good design practices mentioned in this thread, however, are still advisable.

 

Answer 15

SP1 didn't fix my problems.  WF Designer always takes at least 5 minutes to load.

Answer 16

I really can't see any performance difference. If there is any it's not noticeable for my scenarios.

I've spent a long time digging into the designer source code, using Reflector and I can see why is there a performance problem: everything has to eventually become a bitmap drawing, shapes overlap, nothing can be assumed cache-able as it may change in appearance...

Still today's computers can draw crazy 3D graphics with megabytes of texture data and many thousands of triangles (not to mention AA, bump-maps etc) at amazing frame rates. What exactly is Microsoft's excuse for being unable to do that???

Answer 17

What, you mean all those Thread.Sleep() calls don't improve performance ?

 

Face it.  Microsoft doesn't care 1 iota about the performence of any of their products.  Their answer has always been upgrade your hardware.  The problem is that at the rate they  churn out inneficcient code, the likes of Intel and AMD just can't keep pace.

 

I have a 3.6 Ghz core 2, with 8 Gig of RAM and  raid setup with 3x 11000 rpm SATA II disks (stripping), and it's still a freaking DOG to load up any but the most trivial of workflows.

 

It's always amazing to watch the performance monitor stats for page faults while this is going on.  My whole directory tree ( compiled solution with source code, and pdbs, etc..) weighs in at about 250 Meg, so why Visual Studio is ever going to disk (after the first build) is beyond me.

 

Basically, Windows Workflow Sucks

Answer 18

Oh, yeah.

Did I mention that even with a small project with unbelievably trivial workflows, the designer still randomly provides the 'White Screen of Death' with some incomprehensible error message that is actually a complete lie.

The only way to solve the issue is :

Close Visual Studio
Ensure no 'rogue' devenv.exe task is somehow still running
Reboot

Great, that's a real productivity enhancement.

Answer 19

Just to add 'gazoline on fire' ....

I started working with WF on 2006 with first 'Windows Workflow extension for Visual Studio 2005'

Since this time i added many bugs on microsoft connect such as

- StateMachineWorkflow designer autoredraw move nested states outside container
http://connect.microsoft.com/wf/feedback/ViewFeedback.aspx?FeedbackID=323899
- StateMachineWorkflow designer is too slow
http://connect.microsoft.com/wf/feedback/ViewFeedback.aspx?FeedbackID=323904
(you may find about other ten bugs signed by me as 'fedeballan' such as 334484, 334463, 323934,323947, 323981, 323938, 323936, 3320000)

 

On all these bugs answer were:

1) postPoned

2) closed

At the end, i wait alway for the 'next' version: so , vs2005 sp1, vs2008 and at least vs2008Sp1.

Nothing was changed (on the contrary vs2008Sp1 is littlebit more unstable).

So I opened a incident, the SRQ081015600079, still open.

In the middle, i tested also the new Vs2010 CTP (31 october 2008): still nothing has been changed.

 

This is a question for WF developing team:

after this 2-3 years, how long do we have to wait for a usable tool?

May you give us some time hints?

 

on the end ... Thank you.

Federico Ballan

Answer 20

I feel your pain.

 

While many of your referenced 'bugs' (334484, 334463, 323934,323947, 323981, 323938, 323936, 3320000) are actually enhancement requests, I agree that performance - in this case - shouldn't be considered an enhancement.

 

Visual Studio Workflow Designer becomes practically unusable with anything other than the most trivial of workflows.  Microsofts suggestion that you may be able to mitigate some of this by re-organizing your solution into a myriad of smaller projects is bogus on two counts.

 

Firstly, this have never been suggested in any official documentation about working with Workflow Designer.

Secondly, having spent over a week redesigning my solution to obey the recommendation, I experienced no noticable effect.

 

As for your question about how long we should wait for a usable tool, my only advice is - Don't hold your breath.

 

And of course, by contributing to this thread, you've likely been blacklisted. 

 

The only reason I continue posting here is to warn prospective users of WWF to stay away, far away, and to ensure this thread doesn't drop too far down the list where it won't be found.

Answer 21

 

At this point I really hope Mr Lorenz Pren (the WF product manager) should read this thread: it's name was given me by my microsoft contact for the Service Request SRQ81015600079 and i wish notify him for the following question:

 

1) how many programmers in MS uses WF to build a competitive product ?

1.1) Does they do not report any feedback on using it?

2) do you known how many hours we spend in using this 'unusable' tool

3) do you know how many time first, my product manager call me for the product? and seconds my customer ask me for new functions?

 

I know that WF is free on Visual Studio and .NET framework: but this is not enough to justify the time (and money) loss in production: on this consideration, as a developer,  i would like to ask a price for a complete and well running tools in the same way my customer ask me for a my products.

 

... and note i wrote 3 workflows: wf.a with 10 states, wf.b with 40 states, wf.c 32 states: I am lucky to have written the most of the product logics on Vb.net code.

 

In the end I would like to ask when a new designer should be available: looking my history (two years and more) and the others and also the structure of the designer (it seems to me that it consist about ten dll's) I think a new Visual Studio 2008 Workflow Extension stand alone setup should be provided (excepting the fact if  Vs2010 specific features will be required).

 

Federico Ballan

Answer 22

I've spent almost 2 months optimizing a customized version of the designer and I should say results are better than what's posted above.

I used a stylesheet to convert a client's script files to WWF and some of those scripts have several hundred steps and I'm still able to edit them with my customized designer.

This only comes to prove Microsoft doesn't give a damn about their products.

Answer 23

As just confirmed by Microsoft personnel, and also looking the count of the wrong experiences of WF developers in this thread, and also looking for the long time to have the new WF 4.0 desinger (in 2010...), may you publish and share your customized version of WWF designer in some code community?

 

Thank you

 

 

Answer 24

At this time I'm unable to publish the code freely - I'm developing a product which has WF designer in its core. Another complication is that the optimization is a customization of the designer by Microsoft and it's a little more involving than just adding a few methods here and there - there is deeper integration between the designer and another component used in the product.

If you're looking for commercial application of the designer then we can arrange something in a more formalized business way. A reply here should do (I'm not checking the forums all the time), or use Skypeetrowi

Answer 25

Thank you, sorry i did not understand that you worked on a commercial package: I supposed you found a fix or a workaround for the many bugs of the designer.

I'm just waiting for a Microsoft answer on a incident opened for the autoRedraw of the StateWorkflow designer to disable this 'feature' that destroy my layout many times in a day of work.

Did you work about this behaviour?

Thank you

 

(at this time I have not SkyPe)

Answer 26

One of the performance problem with the original designer is that it draws even things that are not on the screen. It does that because a large shape that is bigger than the view can still have visible parts.

In my shapes' custom drawing I made some additional checks on should the shape appear or not, cached some values (sizes, shape values) and optimized the heck out of what had to be there. The UI on top of the designer has some aids to facilitate the visualization by a slow designer (hot keys for fixed zoom, pan, select) - these don't speed up the designer, they just make it easier to live with a slow one.

I haven't dealt specifically with StateWorkflow, but the basic idea is this: get Reflector, see what does StateWorkflow do and implement your own with custom drawing. Not the most pleasant task for sure, but it can help.

Answer 27

Thank you for hints: now I try to survive following the Wf desing guideLine of mr. Lorenz Pren (the MS Workflow product manager). because my business is automating vending machine, not a Workflow developing (but this is only for controversy discussion with MS (I hope they read this forum)).
If current open incident will not be resolved in a reasonable time, I think I will ask you for more hints or support.

But, in the end, why don't you sell your base extensions as a stand alone product? I think a number of  'desperate developers'
should appreciate it!

Thank you again.

Answer 28

I'm not selling anything yet, but I will in a couple months. I need to finish work on 2 workflow activity libraries that would make the product applicable to real tasks. I'll take your pointer and allow for using the product's libraries in its EULA

Answer 29

Well, looks like I'm not the only one to suffer from performance issues with WF Designer.

Besides workflow development, my team and I are also working on the development environment that consists in part of a rehosted designer. Added to that, we also have developed our very own custom flowchart engine (since neither sequence workflows or state machine workflows were acceptable for our client's experience).

The whole job involves a lot of custom ActivityDesigner and SequenceDesigner classes, so pratically every box object in the designer screen has its ActivityDesigner.OnPaint() method overriden.

As one builds up a workflow, performance is initially good (better than using VS2008), but as the number of objects grows larger, performance goes all the way down.

The scenario is even worse when loading a big workflow; scrolling around and dragging new objects into the designer throws CPU usage to the ceiling.

I have tried to use call WorkflowView.SuspendLayout() and WorkflowView.ResumeLayout() when WorkflowView.DragEnter /WorkflowView.DragDrop /WorkflowView.DragLeave events are generated, but I couldn't get any performance improvement. My idea was temporarily avoiding ActivityDesigner.OnPaint() to be called, but apparently I missundertand Control.SuspendLayout() funcionality, or it absolutely doesn't work for the scenario I described.

So, despite taking Raidah's suggestion to do Microsoft's work (wasn't that what Raidah did, rewriting the designer from scratch?), is there anything I do to improve performance? Is there any other way to programatically disable and re-enable ActivityDesigner.OnPaint() calls?

Please, no project reorganization tips here, we all tried that. :-)

---

-- Rafael www.nerdcore.com.br

Answer 30

Hi Microsoft,

I have a proposal for this.  I know in .Net 4/VS2010 there are new "breaking" changes that claim to fix the issue.  But realize that that'll cause great inconvenience to the existing users of WF 3.0/3.5.  Also realize that there are no issues with the workflow engine, etc.  only with the designer.  So please help us by solving the designer issue.  Here is a potential solution:

Instead of parsing the whole world everytime "Design" tab is clicked for a workflow ---- mark it "dirty" and provide a way to click a button/menu to "REFRESH" the workflow.  This action should parse the whole world or whatever it needs to do.  This way atleast when changing a few "independent" things in the workflow will run fast --- my guess is the "independent" items do not need the entire solution parsing.  90% of the time we are just changing items that apply only to the specific workflow.  So please do us a small favor and allow the ability to manually "refresh" the workflow.

Thanks,
VJ

Answer 31

Hello community, I was working on this problem for several months. In my case I and my development team conducted several activities were encapsulated complex workflow to complete other workflow where roads were reused in different paths. In this scenario the workflow inicialization to run is very slow and consumption very amount of ram an when start and in the moment to desing the workflow in visual studio is very slow.

We noticed that the slowness was caused to the activities that were scheduled were too large and complex and required each activity at least 10 MB of RAM when added to the designer and had models at least 50 of these, which came into that VS2008 to consume 900 MB of RAM for the time of design and validation flow.

We estimate that this worklow was then composed of thousands of activities being charged as a single workflow and you think that by being composed in other Visual Studio components and references are not loaded, as they are of the same type and should have charged only once and not every time it is called within the flow, which is completely wrong in WWF.

"This problem is caused by a poor analysis of the negotiation process by not defining the scope of workitems, trying to represent workflows very large and complex in Windows Workflow Foundation."

To resolve this situation decompose the workflow into smaller workflows to reach an operational atomic component, then call them with a chaining these invoqueanotherworkflow activity and to build the superior process and remember to monitor in some way the conditions of these atomic workflows.


Bye,

Answer 32

Just want to throw my two cents into this thread, and hope it works it's way to the development teams at Microsoft.  I am developing State Machine workflows for my company using VS2008, and it is very frustrating for the following reasons:

- Binding properties causes 15-20 second hangs.
- Opening a designer window takes anywhere from 30-60 seconds.
- Basically, anything touching the designer window, any clicks, etc. take a minimum 15 seconds of Visual Studio being frozen up.

My workflows are pretty small (definitely less than 20 states, probably around 10 on average), and my development machine is pretty powerful.  Anything you can do to increase performce will not only increase productivity of your partners, it will also increase perceptions of the product.

Regards,
Matt

Answer 33

Just want to throw my two cents into this thread, and hope it works it's way to the development teams at Microsoft.  I am developing State Machine workflows for my company using VS2008, and it is very frustrating for the following reasons:

- Binding properties causes 15-20 second hangs.
- Opening a designer window takes anywhere from 30-60 seconds.
- Basically, anything touching the designer window, any clicks, etc. take a minimum 15 seconds of Visual Studio being frozen up.

My workflows are pretty small (definitely less than 20 states, probably around 10 on average), and my development machine is pretty powerful.  Anything you can do to increase performce will not only increase productivity of your partners, it will also increase perceptions of the product.

Regards,
Matt