Rails-使用局部视图是否会减慢视图渲染？

我在Rails 3.1.0应用程序上遇到性能问题，现在我已经使用AR对查询进行了球型更改，因此视图仍然需要太多时间来呈现，我将视图，循环等划分为许多部分，在视图内部和其他局部内部动态渲染。

因此，拥有大量的局部片段是一种不好的做法？

是否应该减少局部数以改善视图渲染时间？

谢谢

当您渲染相同的内容时，我知道许多局部视图和一个视图之间没有显着的渲染性能差异。

显然，如果在某些情况下仅渲染某些部分，而在其他情况下仅渲染其他部分，从而有效地减少了特定视图的渲染量，则可能会提高速度。

另一方面，我一直在考虑局部抽象，至少应该在两个不同的地方使用局部抽象来证明它们的存在。使用partials的另一个原因是当您要呈现相同的视图但根据您拥有的某些业务逻辑加载不同的partials时。

更新：

我无法提供有关渲染速度的度量或一些具体数字。如果在视图中使用局部视图，则要渲染它，请调用render方法，因此有第二个方法调用。就像我在回答中说的那样，这几乎没有什么用，但可能会帮助加快速度。

但是，我从未听说过通过除去部分零件来解决其性能问题的项目。分部是为视图提供重用机制的好方法，从程序员的角度来看，应将其用于该范围。它们应该是视图中常见概念的抽象。

我参与了一个过度使用局部函数的项目。不是Rails，而是相同的MVC原理。在您可以想像的所有内容上使用很少的局部，当您开始拥有数十个局部时，很难找到它们。您在哪里寻找要修改的输入？在视图中？在部分？此视图中哪个部分有4个局部？...

经过一番艰苦的重构，对于视图的每次更新，我们都删除了不必要的部分。它们并没有完全消失，但是剩下的是为项目定义的抽象。它们代表了众所周知的元素（例如某种对象的树或特定的列表类型），它们以某种形式或在其他视图上重复出现。我知道如果我看到一棵树，那有一部分。我知道当我看到某种类型的列表时，会发现其中有一部分。我没有追捕他们。

代码可读性是软件代码库可以做的最重要的事情。

我不同意这两个答案。我已经将代码从局部复制并粘贴到了它在父视图局部中存在的位置，并且经过了500次迭代，渲染视图所需的时间减少了600毫秒。我认为<％= render xyz％>非常坏。

例如，渲染视图的总时间：

Before:
5759.8ms
5804.2ms
5973.6ms

After:
5268.7ms
5201.6ms
5222.4ms

Diff = 5846 - 5231 = 615 ms

已编辑

我最终取消干燥_model部分中的所有_partial，并将其降低到〜2000ms，这时我尝试将_model部分移动到索引中，但是这对渲染时间没有任何影响，所以我猜想它与嵌套渲染的调用有关可以。

不是铁杆家伙，但部分视图本身可能不是问题。相反，听起来您正在执行SELECT N + 1。从数据库服务器的角度来看事情，以确保您不会打败它。

现在正在使用Rails 4.2应用程序，其中缓慢的动作平均耗时约745ms。

当我从部分代码中删除代码并将其放入主模板时，现在平均花费的时间少于25ms。

渲染部分的调用次数仅为29。

即使您没有n + 1问题，并且所有数据库都已预先工作（例如使用递归CTE），嵌套的部分仍然非常慢。Haml和Erb对我来说都很慢。在Rails 5.1.4上，我看到每个部分都需要几毫秒的时间，偶尔还会有更差的部分（可能对应于垃圾回收）。

我注意到，如果我在运行这些请求之一时重命名了partial，则会立即收到有关如何找不到文件的错误。因此，很明显，Rails正在读取磁盘上的部分磁盘，对其进行重新解析，并针对每次迭代对其进行评估。难怪它很慢！

嵌套部分中出现的许多缓慢现象仅在开发期间发生。切换到生产进行测试。