ruby-on-rails - helpers 真的比 partials 快吗？弦乐 build 呢？

Question

我在 Rails 应用程序中有一个花哨的“工作表”样式 View ，加载时间太长。 (在开发模式下，是的，我知道那里没有缓存，“在 57893 毫秒内完成(查看:54975，DB:855)”)工作表是使用辅助方法呈现的，因为我无法忍受为工作表中不同类型的行。现在我想知道 partials 是否真的会更快？

我已经分析了页面加载并确定了一些对象缓存将减少几秒钟的情况，但配置文件输出表明大量时间用于简单地循环通过 Worksheet 模型的组成对象并附加字符串输出 helper 。这是我正在谈论的一个例子:

def header_row(wksht)
  content_tag(:thead, :class => "ioe") do
    content_tag(:tr) do
      html_row = []
      for i in (0...wksht.class::NUM_COLS) do
        html_row << content_tag(:th, h(wksht.column_headings[i].upcase),
                                :class => wksht.column_classes[i])
      end
      html_row.join("\n")
    end
  end
end

OTOH 使用 partials 意味着打开文件，分离 Ruby 解释器，从长远来看，聚合一堆字符串，对吗？所以我想知道是否有另一种方法可以加快助手的速度。我应该使用类似 stringstream 的东西(在 Ruby 中是否存在？)，我是否应该摆脱 content_tag 调用以支持我自己的“”字符串插值......我愿意编写自己的性能测试，并分享结果，如果您对我已经采取的方法有任何建议的替代方案。

由于这是一个相当复杂的 View (并且也有一个可编辑的版本)，我宁愿不要多次重写和分析整个事情。 :)

一些相关阅读:

http://www.viget.com/extend/helpers-vs-partials-a-performance-question/ (老的)
http://www.breakingpointsystems.com/community/blog/ruby-string-processing-overhead/
http://blog.purepistos.net/index.php/2008/07/14/benchmarking-ruby-string-interpolation-concatenation-and-appending/

@tadman:
有行总计和列总计(以及更多的列式算术)，并且由于它们不仅仅是总计，而且还依赖于数据库中的其他“魔数(Magic Number)”，因此我在 Ruby 代码而不是 Javascript 中实现了它们。 (干燥且可单元测试。)Javascript 仅用于编辑 View ，仅用于添加/删除行(仅限客户端)并在单元格内容更改时获取包含新总数的工作表。它获取整个表格，因为当输入单元格更改时，将近一半的值会更新。

工作表及其行实际上是虚拟模型；它们并不存在于数据库中，而是聚合了大量真实的 AR 对象。每次渲染 View 时都会创建它们(但在开发模式下需要 1.7 秒，所以我并不担心)。

我想我可以传输一个数字矩阵，而不是标记的内容，然后让 JS 将其解压缩到工作表中。但这很快就无法维护。

Answer 1

我最终在 http://www.infoq.com/articles/Rails-Performance 上阅读了一篇出色的文章(“查看 Rails 中的常见性能问题”)。然后我按照作者的建议在请求处理期间缓存计算:

def estimated_costs
  @estimated_costs ||=
    begin
      # tedious vector math
    end
end

因为我的工作表一遍又一遍地执行上述操作，然后在这些结果的基础上计算更多行，这导致了 90% 加速 马上开始。本来应该一帆风顺的，但一开始只有几个总数，然后我向客户展示了原型(prototype)，它从那里滚雪球:)

我还想知道我的基于数组的数学是否效率低下，所以我用 NArray ( http://narray.rubyforge.org/) 替换了 Ruby 数字数组。加速可以忽略不计，但代码更干净，所以它保持这种状态。

最后，我放置了一些对象缓存。数据库中的“魔数(Magic Number)”一年最多只变化几次，其中一些是加密的，但在大部分计算中都需要用到。这是缓存的成熟果实，它又缩短了 1.25 秒。

接下来我将看看关联的急切加载，因为可能有一些时间可以保存在那里，我将按照@tadman 的建议对发送“仅数据”与发送 HTML 进行快速比较。关于我可以缓存的唯一部分是导航侧边栏。所有其他内容取决于请求参数。

感谢您的建议!