performance - 工作流设计器非常慢。是 Xoml 吗？

Question

我有一个 WF 状态机，我用它来处理 WPF 媒体中心应用程序上的页面导航。它有六个状态，每个状态都有初始化处理程序和一个或两个 EventDriven 处理程序。

当您首次使用 VS 模板制作 StateMachine 工作流时，您可以选择使用代码隐藏模型或代码分离模型，其中工作流拓扑在 .Xoml (xml) 文件中进行描述。

最近，每当我使用状态机时，Visual Studio 会间歇性挂起长达 10 秒，之后它总会恢复。

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

任何人都对任一模型中的 Workflow Designer 性能有相关经验？

Answer 1

这是 visual studio 2008 中工作流设计器的一个众所周知的问题。我们被 promise 在 sp1 中进行改进(并且应该得到它们，但我没有注意到任何东西)。建议包括:

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

将接口(interface)、事件类型、自定义事件、助手类移动到不同于工作流所在的项目。例如。在客户的解决方案中，大约有 10 个项目，每个项目有 10 个工作流和 10 个关联的事件类型。每次用户更改项目中的工作流时，这些类型都会重新解析以更新以构 build 计时类型信息。将这些移动到不同的程序集(例如，只有一个项目具有 10 个工作流项目所需的所有类型)将有助于提高性能。

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

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

将大型状态机工作流重构为较小的工作流

我们从客户那里发现的一个示例在同一工作流中有 780 个状态和 1000 个事件绑定(bind)，导致大约 16000 行的 InitializeComponent()。将此状态机分解为更小的可重用工作流程将使设计人员的性能更好，并减少大量冗余状态。

不要在事件构造函数中做长时间运行的工作

事件构造函数在设计时也会被调用，因此永远不要在构造函数中执行诸如连接数据库等操作，这会使设计人员花很长时间打开使用这些事件的工作流文档。

发件人:http://blogs.msdn.com/madhuponduru/archive/2008/09/30/workflow-designer-and-performance.aspx

-奥伊辛