据布拉德·威尔逊， 是的RenderAction比的RenderPartial较慢。
但是，有没有人得到了显示性能上的差异的统计数字？
我公司发展中的页面是由“部件”的应用程序的过程。
我有两个选择：
成分在视图级别
呼叫为的RenderAction每个插件。 这是迄今为止最简单的方法但并不意味着我们对每个插件执行完整的MVC周期。
成分在控制器级别
撰写一个视图模型为包含我们需要为每个插件的数据的页面。 打电话的RenderPartial为每个插件。 这是更为复杂的实现但并不意味着我们会做只有一个MVC周期。
我测试3个不同的窗口小部件的上述方法在网页上，并在渲染时间差为第二的十分之（几乎不值得担心）。
但是，有没有人有任何的测试结果比这更具体，或者是想体验这两种方式？
我最近在弄这是遇到性能问题的应用程序，并发现这是做四次调用到的RenderAction，再加上另外一个布局中的视图。 我发现，每次调用的RenderAction - 甚至当我在返回一个空视图诱敌动作加 - 花了大约200-300ms（我的本地机器上）。 通过呼叫的数量乘以你在页面上一个巨大的性能损失。 在我而言有四个呼叫造成不必要的有关服务器端的开销第二。 相比之下，调用的RenderPartial是围绕0-10ms的区域。
我会避免使用的RenderAction尽可能赞成的RenderPartial的。 该控制器应负责返回所有必要的信息。 在小部件的情况下，如果你需要几个小部件多个动作，我会尝试将它们组合成一个动作，因此开销的RenderAction只发生一次，但如果您的网站进行充分的我让他们分开更清洁的设计。
编辑：我收集使用MiniProfiler击中的部位此信息。 它不是超级准确，但它明确显示出差异。
编辑：作为奥斯卡低于所指出的，有问题的应用程序可能有，对于在Global.asax的每个请求运行了一些密集的代码。 该命中的大小将取决于应用程序的代码，但是会的RenderPartial完全避免执行另一个MVC周期。
我建议2点更多的选择，都需要撰写的控制器级视图模型和两个可以一起工作（取决于数据）
选项2名的作品非常好，如果你想保持在不同的组件的部件，毕竟他们只是函数返回一个字符串。 我认为它也有最好的表现，当然，你失去了“设计师友好”的模板。 我认为要考虑可维护性方面，不仅原始性能是很重要的（除非您真的需要它，即使如此，缓存是比较有用）。
对于小的东西（日期或名称格式化等）我会使用助手，因为HTML通常是一个班的跨度，对于更复杂的东西，我会使用的显示模板。
