分析Ruby代码

Question

除了ruby-prof和核心基准测试类，你还用什么来分析你的Ruby代码呢？特别是，您如何找到代码中的瓶颈？我几乎感觉我需要在我自己的小工具上工作，只是为了弄清楚我的代码中所有的时间都花在了哪里。

我知道ruby-prof提供了这一点，但坦率地说，输出非常令人困惑，并且不容易找出您自己的代码的哪些实际块是问题的根源(它会告诉您哪些方法调用花费的时间最多)。因此，我并没有真正从它中获得我想要的东西，也没有真正能够利用它。

也许我做错了？还有别的选择吗？谷歌搜索没有给我找到任何东西。

Answer 1

很多分析器都是这样的。你需要知道的不是程序把时间花在哪里，而是为什么。Any references on Dynamic Code Analysis?

添加：Here's how我发现我的代码中存在“瓶颈”。(我讨厌这个词。) Here's a list的原因。

为了找到“瓶颈”，你必须以某种方式进行大量的测量，这是非常自然的。这是非常自然的，几乎所有的分析器都是基于它的。

实际上，发现和测量不是一个问题。需要进行测量，以查看您发现(和修复)的内容是否有影响。对我来说，找到要修复的东西更像是调试而不是测量。

解释它的最简单的方法是从无限循环开始，或者从几乎无限循环开始。你是怎么找到它的？您暂停它并查看堆栈，对吗？因为你知道问题出在堆栈上的某个地方。您只需暂停它一次，然后您需要研究堆栈上的代码。如果你想确定你已经找到了，就暂停几次。

假设代码只需要所需时间的两倍。这意味着当你暂停它时，有50%的机会你会看到它在做不必要的事情。如果你暂停它并看10次，你会在动作中捕捉到它大约5次。事实上，一旦你看到它在做一些你可以在2个样本上进行优化的事情，你就会发现一个“瓶颈”。修复它，测量加速比，展示它，然后重复。

即使你最大的问题不是很大，这个方法最终也会找到它。此外，还有一种放大现象，在删除较大的问题后，小问题变得更容易发现。这使您可以继续执行，直到代码接近最优。

附注:在你完成这项工作之后，可能还有加速的机会。例如，优化算法可以依赖于数值稳定性。消息驱动架构会使跟踪代码执行的原因变得更加困难。在实时软件中，性能问题可能只会偶尔发生，而且不太容易采样。这需要更多的机智。仅仅依靠测量是行不通的。

Answer 2

要真正深入到您的代码中，请尝试stackprof。

这里有一个关于如何使用它的快速解决方案:安装gem：gem install stackprof。在你的代码中添加：require 'stackprof'并用下面的代码括起你想要检查的部分：

StackProf.run(mode: :cpu, out: 'stackprof-output.dump') do {YOUR_CODE} end

运行ruby脚本后，使用stackprof stackprof.dump在终端中检查输出

Mode: cpu(1000)
Samples: 9145 (1.25% miss rate)
GC: 448 (4.90%)

 TOTAL    (pct)     SAMPLES    (pct)     FRAME
   236   (2.6%)         231   (2.5%)     String#blank?
   546   (6.0%)         216   (2.4%)     ActiveRecord::ConnectionAdapters::Mysql2Adapter#select
   212   (2.3%)         199   (2.2%)     Mysql2::Client#query_with_timing
   190   (2.1%)         155   (1.7%)     ERB::Util#html_escape``

在这里，您可以看到所有需要花费大量时间的方法。现在最棒的部分是:要深入研究，只需执行stackprof stackprof.dump --method String#blank?，您就可以获得特定方法的输出：

String#blank? (lib/active_support/core_ext/object/blank.rb:80)
  samples:   231 self (2.5%)  /    236 total (2.6%)
  callers:
    112  (   47.5%)  Object#present?
  code:
                                  |    80  |   def blank?
  187    (2.0%) /   187   (2.0%)  |    81  |     self !~ /[^[:space:]]/
                                  |    82  |   end

而且您可以很容易地找出代码的哪一部分需要花费大量时间来运行。

如果你想得到一个可视化的输出，使用stackprof stackprof.dump --graphviz >> stackprof.dot (brew install graphviz) dot -T pdf -o stackprof.pdf stackprof.dot得到一个漂亮的PDF输出，它突出显示了需要很长时间才能运行的方法。

Answer 3

这是我自己的问题，但是我发现了一个非常棒的分析工具，所以我必须在这里添加它：

http://samsaffron.com/archive/2013/03/19/flame-graphs-in-ruby-miniprofiler

与查看回溯相比，火焰图使性能问题的根源变得惊人地明显。