我有一个WF状态机，我用它来处理WPF Media Center App上的页面导航。它有六个状态，每个状态都有初始化处理程序和一个或两个EventDriven处理程序。
当您首次使用VS模板创建StateMachine工作流时，您可以选择使用代码隐藏模型或代码分离模型，其中工作流拓扑在.Xoml（xml）文件中描述。
最近，每当我使用状态机时，Visual studio会间歇性地挂起长达十秒钟，之后它会一直恢复。
这可能是Xoml解析中固有的问题，如果我使用代码隐藏模型重做状态机会消失吗？
任何人都有关于任一模型中Workflow Designer性能的相关经验吗？
答案 0 :(得分：4)
这是Visual Studio 2008中工作流设计器的一个众所周知的问题。我们承诺在sp1中进行了改进（并且据说得到了它们，但我没有注意到）。建议包括：
将工作流程中使用的所有类型移动到与工作流程所在的项目不同的项目。
将接口，事件类型，自定义活动，帮助程序类移动到与工作流所在的项目不同的项目。例如。在客户的解决方案中，大约有10个项目，每个项目有10个工作流程和10个相关事件类型。每次用户更改项目中的工作流程时，都会重新解析这些类型以进行更新以构建设计时类型信息。将这些移动到另一个组件，例如只有一个项目具有10个工作流项目所需的所有类型，将有助于提高性能。
减少项目中的工作流程数量。
每个工作流都是一种类型（直接在c＃/ vb中，间接在xoml情况下），需要通过解析来构建设计时类型，因此如果项目中有10个工作流，则打开项目中的任何工作流第一次意味着解析所有其他工作流程。根据这些工作流程的功能对这些工作流程进行分类，并将它们分组到每个项目的2-3个工作流程中，从而大大提高了性能。
将大型状态机工作流程重新分解为较小的工作流程
我们从客户发现的一个示例有780个状态，1000个活动在同一工作流程中绑定，导致InitializeComponent（）大约16000行。将此状态机分解为更小的可重用工作流程将使设计人员的性能更好，并减少许多冗余状态。
不要在活动构建器中进行长时间的工作
活动构造函数也在设计时调用，因此在构造函数中不应该进行连接到数据库等操作，这可能会使设计人员花费太长时间来使用这些活动打开工作流文档。
来自：http://blogs.msdn.com/madhuponduru/archive/2008/09/30/workflow-designer-and-performance.aspx
-Oisin
答案 1 :(得分：0)
VS 2008给了我你所描述的同样非常缓慢的行为。
我一直在使用VS 2010中的同一个WF项目（在Win 7 RC VM中），性能似乎有了很大提高。至少，图表布局不会像2008年那样迷失。
所以也许对未来抱有希望。