VS2008 Workflow Designer is Very Slow

Question

Yes, I realise that this is a known issue. And has been known since VS2005.

We, too, are experiencing very slow response in the WF designer, running VS2008. It happens on both XP and Vista. (We are using grunty computers, running Subversion, with a local repository, and ReSharper.)

Will increasing CPU power or RAM or HD speed have any impact?

While this has been acknowledged by Microsoft as a "known problem" it would help immensely if someone from Microsoft could say that it is under investigation and that one or more people have been assigned the job of sorting it out for a later (unspecified) release.

Otherwise the advantages of a DSL are outweighed by the pain during development, and what appears to be a good choice of tool may have to be put aside for an alternative approach that is more productive.

Any answers?

Answer 1

This thread contains more details on this topic:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2285994&SiteID=1

 

We are in fact investigating a complete redesign of the editor in one of the upcoming VS releases. Details are not yet final or ready for public consumption. You can help us by telling us about your use case. How large of a workflow do you want to build?

 

 

Answer 2

I'm pleased to hear that this is not being ignored. And I'd recommend that you give this a high priority, so that it comes out in a service pack or hot fix ASAP.

 

I'm happy to offer to beta test your new design, too.

 

Our product is about 1/4 completed. Currently it contains about 20 workflows, each containing between 1 and 8 custom activities. At the moment these are all in one project, so we will investigate partitioning the project for better performance.

Answer 3

Presumably the slow performance of the workflow designer can be mitigated -- to a degree -- by upgrading the hardware?

If so, what is the limiting component at the moment? RAM? CPU? Hard disk (seek or data transfer speed)? Would adding CPU cores help?

The big question: after upgrading the hardware, would I notice a speed difference with the workflow designer?

Answer 4

LorenzP wrote:

This thread contains more details on this topic: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2285994&SiteID=1   We are in fact investigating a complete redesign of the editor in one of the upcoming VS releases. Details are not yet final or ready for public consumption. You can help us by telling us about your use case. How large of a workflow do you want to build?

 

In my particular case, I have a workflow with 5 states. One state has about 5 activities and another state 9 and the faulthandler of one state has 5 activities in it. Visual Studio easily freezes for 30 seconds every time I touch ANYTHING inside Visual Studio 2008. If I host the designer outside VS2008, my Workflow renders super fast so it must be something with the xoml synchronizing in VS2008 that's slowing it down. I have a good idea for a SUPER quick fix while you guys are redesigning the whole thing. Is it possible to make the 2-way syncing "optional"? And, allow the dev to manually click a button/menu to synchronize the designer and the xoml? I mean, I have a 2.4Ghz Core 2 Duo and 4 Gigs of RAM and the whole design process is unusable. BTW, I am running on an XP box.

 

 

Thanks

Answer 5

We are having the same problem and about to kick project. I'm thinking of creating my own workflow struct in XML and a user interface for inserting states and rules.

I created a state machine project with 205 states and about 90 rule conditions. and now when I press to create a new rule condition VS2008 just hangs for exactly minumum 5minutes. It's not acceptable.

We spent 2weeks to develop the structure for .NET Workflow foundation and now my director wants me to quit working on .NET Workflow and there are alternative open source projects like pentaho...

If a new SP is not coming it'll be all garbage

Answer 6

 

It's weird. the WF designer is very fast when hosted anywhere else. It's in VS2008 that it's very slow.

Answer 7

We have fixed our problem, for now, by severely restructuring our solution. Instead of two projects, we now have about 20 projects. The main aim was to put all the custom type definitions into their own project/s, so that WF does not reparse them each mouse-click.

 

That improved responsiveness from 2 minutes down to "instant".

 

I'd still like to know what hardware is the bottleneck? CPU, RAM or HD speed?

 

And if the designer runs fast in other environments, why is it so hard to make it run fast in VS2008?

Answer 8

Dividing project into 20 projects shouldn't be solution. There should be some real solution for the problem.

I have state machine (still grows) 250 state activity on the same wf. I somehow found out that if you add any state activity or a rule conditon, workflow slows down just after that moment. But if you just change the current object properties, it is not so slow. So I'm trying to create my objects and rule conditions at once externally (with a tool I coded). Then I close/reOpen project. And works normal.
Though It's not a radical solution, what can we do!
SOS Microsoft

Answer 9

David in NZ wrote:

We have fixed our problem, for now, by severely restructuring our solution. Instead of two projects, we now have about 20 projects. The main aim was to put all the custom type definitions into their own project/s, so that WF does not reparse them each mouse-click.   That improved responsiveness from 2 minutes down to "instant".   I'd still like to know what hardware is the bottleneck? CPU, RAM or HD speed?   And if the designer runs fast in other environments, why is it so hard to make it run fast in VS2008?

My workflow project only has the 2 workflow.xoml files in it. All the activities (about 15 of them) live in a separate project. The workflow designer is still just as slow. No improvement.

Answer 10

This is ABSOLUTELY KILLING MY PRODUCTIVITY.

 

I thought that with VS2008 SP1 the permformance problems would be resolved but there has been NO improvement whatsoever.

 

I am going nuts. Every time I click on anything in the worklfow the processor kicks up and I have to wait about 30 seconds. And I have a FAST computer. All MAX scores on the windows performance index if that means anything.

 

Is there ANYTHING I can do to finish this workflow without having to write the whole thing by hand in XAML?

 

This is TERRIBLE - and it's even worse on my souped up Vista box at home than on my rinky-dink laptop at work.

 

GRRRRR!!!

 

Answer 11

As the person who started this thread, I can only suggest that you move everything that you can out of the workflow project into a separate project.

(If it's still slow after that, can you split up the remaining workflow project into even smaller individual workflows?)

I feel your pain -- it is not a pleasant development experience.

Answer 12

I find it difficult to believe this thread and similar threads remain unresolved and no still no comment from Microsoft.

 

VS 2008 SP1 has not provided any performance improvements for the Workflow deisgner.

 

Environment:

Windows Server 2003

VS 2008

State Machine Workflow with seperate XOML file.

 

I have a single workflow containing 6 states and an average of 12 EventDriven activities within each state. Each EventDriven activity has exactly 1 Code activity contained within a ReceiveActivity.  (more to be added - hopefully)

 

Performance within the designer is comparable to that experienced by others on this thread making it very difficult to continue with our workflow project.

 

Can someone from Microsoft please comment on when a fix will be provided?

 

In the meantime, a workaround to this "bug" -- other than breaking a 6-state workflow into 6 workflows -- will be appreciated!

 

Thank You,

Roland

Answer 13

Well, David, that's what I ended up doing (restructuring my projects) - and the performance has improved. HOWEVER, it must be noted that that a workaround that requires this level of mutilation - going so far as to actually affect the architecture, is ridiculous. I cannot believe that a company as large and (generally) competent as Micorosoft can realease such a terrible tool and NOT FIX IT for years.

 

I can safely say that all of the XAML-based designers are of poor quality - both in function and performance - but the WF designer is absolutely the worst.

 

??!!??

Answer 14

I have a project with two workflows, and all the custom activities I've created are in two separate projects. The two workflows have around 50 activities each. The problem is that I can't split them into multiple workflows, as it is a ReceiveActivity for WCF web service.

I'm experiencing extremely slow response when updating anything in the workflow. Any suggestions???

Answer 15

I do most of my dev work on VPC's - Server 2k3, always at least 2gig's RAM, VS 2k5 and VS 2k8...  Up until now, I've had absolutely no problem with the WF Designer.  Much to my dismay - I try some WF development on a new VPC and everything goes down the toilet.  Designer takes >= 5 minutes to load a NEWLY CREATED workflow project. grrrr.

Not very uplifting to see this thread having gone on so long...

Answer 16

Somebody from Microsoft please take of this --- the designer is terribly slow and is almost unusable.  Makes me regret using Windows Workflow in the first place and I am sure lot of developers out there feel the same way.  Just as an example: I was doing a code review and normal code it takes 1 hours but due to the slowness of the workflow designer --- it took me 3 hours!!! 

 

Please please fix it so it's not parsing every single file in project (i have lots of workflows in the project).   Also note: My CPU usage is only 30% and there is over 500MB of free Physical RAM so obviously it's not because of my hardware.

Answer 17

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