Performance 工作流设计器异常缓慢。是Xoml吗？

我有一个WF状态机，用于处理WPF Media Center应用程序上的页面导航。它有六个状态，每个状态都有初始化处理程序和一两个事件驱动处理程序

首次使用VS模板创建状态机工作流时，可以选择使用代码隐藏模型或代码分离模型，其中工作流拓扑在.Xoml（xml）文件中描述

最近，每当我使用状态机时，VisualStudio都会间歇性挂起长达10秒，然后它就会恢复

如果我使用代码隐藏模型重做状态机，这可能是Xoml解析中固有的问题吗

---

是否有人在这两种模型中都有工作流设计器性能方面的相关经验？

这是visual studio 2008中工作流设计器的一个众所周知的问题。我们得到了sp1的改进承诺（据说已经得到了，但我什么也没注意到）。建议包括：

将工作流中使用的所有类型移动到与工作流所在位置不同的项目。

将接口、事件类型、自定义活动、帮助器类移动到工作流所在的项目之外的其他项目。例如，在客户提供的解决方案中，大约有10个项目，每个项目有10个工作流和10个相关事件类型。每次用户更改项目中的工作流时，这些类型都会重新解析为更新，以生成设计时类型信息。将它们移动到不同的程序集（例如，仅一个项目具有10个工作流项目所需的所有类型）将有助于提高性能

减少项目中的工作流数量。

每个工作流都是一种类型（直接在c#/vb中，间接在xoml中），需要通过解析来构建设计时类型，因此，如果一个项目中有10个工作流，第一次打开项目中的任何工作流也意味着解析所有其他工作流。根据这些工作流的功能对其进行分类，并将其分组为每个项目2-3个工作流，从而大大提高了性能

将大型状态机工作流重新分解为较小的工作流

我们从一位客户那里发现的一个例子是，在同一个工作流中有780个状态和1000个活动绑定，导致InitializeComponent（）大约有16000行。将此状态机分解为更小的可重用工作流将使设计器性能更好，并减少大量冗余状态

不要在活动构造函数中执行长时间运行的工作

活动构造函数也在设计期间被调用，因此在构造函数中永远不应该执行连接到数据库等操作，这可能会使设计者花费太长时间来使用这些活动打开工作流文档

发件人：

---

-Oisin与2008年的比赛给了我和你描述的一样难以忍受的缓慢行为

在VS2010中，我一直在使用同一个WF项目（在Win7RC虚拟机中），性能似乎有了很大的提高。至少，图表布局不会像2008年那样丢失

---

因此，也许未来还有希望。

我终于发现是Xoml。使用代码behined重做项目使WF再次可用。