我有一个包含 5 个行组的阶梯式报告。每个都使用一个表达式作为分组的值。用户最多可以为 5 个不同的参数选择一个值，然后根据这些参数对报告进行分组。
对于某些参数组合，报表可能需要 2 分钟 + 才能在 Visual Studio 的预览窗格中运行。当我将报告部署到 SSRS 服务器时，相同的参数组合会在 10 秒或更短的时间内运行。出于好奇，我创建了一份报告副本，并从每个行组中删除了表达式，并指定了一个要分组的字段。在这种情况下，它的预览速度与在服务器上查看时一样快。
任何人都知道这里可能发生了什么？
我目前正在使用 Visual Studio Enterprise Update 3。
我意识到这是一个较旧的问题，但也许这对您有所帮助。
我遇到的症状与您所描述的相似，归结为在分组语句中使用动态字段。显然，任何其他语句都可以毫无问题地使用动态字段，但分组会导致巨大的性能损失。
此链接概述了症状和原因。
我不知道它是否在那个特定的链接中，但我读到了一些关于 ReportViewer 控件在呈现为 HTML 时如何有一个错误，该错误仅在控件在 .Net 4.0 或更高版本下运行时发生。在 .Net 3.5 中，性能几乎与在 Report Viewer 应用程序中运行 RDL 相同。
如果您能够这样做，让报表查看器组件工作的最快方法是让 IIS 使用的应用程序池在 .Net 2.0（或 3.5（如果有该选项）下运行，因为它们基本相同事物）。
如果您的应用程序将 .Net 4.0 或更高版本用于其他功能，除了重写报告以从分组中删除动态引用之外，我无法弄清楚，但这会显着降低报告的交互性（没有表行/列中的展开/折叠选项）。
作为参考，我有一个报告，其中查询大约需要 2 分钟才能执行，然后如果我在 SSRS 中加载 RDL，之后几乎立即呈现。使用 .Net 2.0 中的 ReportViewer 控件呈现的同一份报告大约需要 2 分 30 秒才能完全呈现。使用完全相同的代码，但将应用程序池更改为使用 .Net 4.0，报告已经“渲染”了大约 15 分钟，但仍未返回。
首先，很明显，如果您在开发机器上运行报表，它的计算能力将不及服务器。即使您从服务器运行 VS，它的运行速度也不会像已部署的报告那样快。
正如您可能注意到的那样，性能缓慢的原因是分组表达式。您的报告似乎需要很长时间才能处理，因此请查看Technet帖子中的这篇文章。我复制并粘贴了下面的一段：
Tablix 数据区域中的许多级别的嵌套组和相邻组会影响报表处理性能。考虑分组的级别、组实例的数量以及需要在应用组、过滤器和排序表达式后进行评估的聚合函数的使用。
我建议您尝试在 SQL 级别在数据源中执行分组，您也可以将参数传递给查询以在此处设置所需的分组。
让我知道这是否有帮助。