34

除了 ruby​​-prof 和核心 Benchmark 类之外，您还使用什么来分析您的 Ruby 代码？特别是，您如何找到代码中的瓶颈？几乎感觉就像我需要使用自己的小工具来弄清楚我的代码中所有的时间都花在了哪里。

我意识到 ruby​​-prof 提供了这个，但坦率地说，输出非常令人困惑，并且不容易找出你自己代码的哪些实际块是问题的根源（它告诉你哪些方法调用花费了最多时间尽管）。所以我并没有真正从中得到我想要的那么多，也没有真正能够利用它。

也许我做错了？有替代品吗？谷歌搜索没有为我带来任何东西。

4

4 回答 4

12

要真正深入了解您的代码，请尝试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，请使用 graphviz ( brew install graphviz)dot -T pdf -o stackprof.pdf stackprof.dot获得漂亮的 PDF 输出，它突出显示需要很长时间运行的方法。

于 2015-06-29T16:35:13.440 回答
9

很多分析器都是这样的。您需要知道的不是程序将时间花在哪里，而是为什么。关于动态代码分析的任何参考资料？

补充：这是我在代码中找到“瓶颈”的方法。（我讨厌这个词。） 这是一个原因列表。

很自然地假设要找到“瓶颈”，您必须以某种方式进行大量测量。这是很自然的，几乎所有的分析器都基于它。

实际上，发现和测量不是同一个问题。需要进行测量以查看您发现（并修复）的内容是否有所作为。对我来说，找到要解决的问题更像是调试而不是测量。

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

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

即使你最大的问题不是很大，这个方法最终还是会找到的。此外，还有一种放大现象，即在您删除较大的问题后，小问题变得更容易找到。这使您可以继续前进，直到代码几乎达到最佳状态。

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

于 2010-11-03T23:49:21.743 回答
3

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

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

相对于回溯，火焰图使性能问题的根源非常明显。

于 2014-01-25T04:26:56.863 回答
3

ruby -rprofile在 Ruby 源代码中也有或等效地，require 'profile'

文档：

https://ruby-doc.org/stdlib-2.1.0/libdoc/profiler/rdoc/Profiler__.html

于 2017-07-12T18:57:33.377 回答