RenderAction与RenderPartial性能

Question

据布拉德威尔逊说，RenderAction比RenderPartial慢。

然而，有没有人有任何统计数据来显示性能的差异？

我正在开发一个应用程序，其中页面由“小部件”组成。

我有两个选择：

视图级别的组合()

为每个小部件调用RenderAction。这是目前为止最简单的方法，但确实意味着我们要对每个小部件执行完整的MVC周期。

控制器级的组合()

为包含每个小部件所需数据的页面编写一个ViewModel。为每个小部件调用RenderPartial。实现起来要复杂得多，但这确实意味着我们将只开发一个MVC周期。

我用一个页面上的3个不同的小部件测试了上述方法，呈现时间的差异是十分之一秒(几乎不值得担心)。

但是，是否有人得到了比这更具体的测试结果，或者可能经历过这两种方法的尝试？

Answer 1

最近，我开发了一个遇到性能问题的应用程序，并找到了一个对RenderAction进行四次调用的视图，以及布局中的另一个。我发现每个对RenderAction的调用--即使我添加了一个返回空视图的虚拟操作--花费了大约200-300 my (在我的本地机器上)。乘以呼叫的数量，页面上的性能就会受到很大的影响。在我的例子中，有四个调用造成了大约一秒的服务器端不必要的开销。相比之下，对RenderPartial的调用在0-10 to的范围内。

如果可能的话，我将避免使用RenderAction来支持RenderPartial。控制器应负责返回所有必要的信息。对于小部件，如果您需要对多个小部件执行多个操作，我将尝试将它们组合成一个操作，这样RenderAction开销只会发生一次，尽管如果您的站点执行得足够好，为了更干净的设计，我会将它们分开。

编辑：，我使用MiniProfiler收集了这个信息，并点击了这个站点。这并不是非常准确，但它确实清楚地显示了不同之处。

编辑:正如奥斯卡在下面指出的那样，这个应用程序可能有一些针对global.asax中的每个请求运行的密集代码。这种攻击的程度将取决于应用程序代码，但RenderPartial将完全避免执行另一个MVC周期。

Answer 2

我建议增加两个选项，这两个选项都需要在Controller级别上组合视图模型，并且两者都可以一起工作(取决于数据)。

1. Html.DisplayFor() -显示模板
2. 通过扩展方法提供帮助

如果希望将这些小部件保存在不同的程序集中，那么选项2工作得很好，毕竟它们只是返回字符串的函数。我认为它也有最好的性能，但你当然失去了‘设计师友好’的模板。我认为考虑可维护性方面是很重要的，而不仅仅是原始性能(直到您真正需要它，即使这样，缓存也更有帮助)。

对于小东西(日期或名称格式等)，我会使用帮助器，因为html通常是一个类的跨度，对于更复杂的内容，我会使用显示模板。