是什么会导致Ruby Nomethoderror回溯如此慢？

Question

我正在开发一个非常大的红宝石（非轨道）应用程序。考虑到它的大小和复杂的数量，这是相当快的快速（请使用Ruby！），但是有时我会用方法名称并获取Nomethoderror。

通常，当这种情况发生时，应用程序将悬挂大约20到30秒以打印出回溯。

具体来说，如果我这样做：

puts "about to crash!"
Array.new().inspekt    # NoMethodError here

我会看到“即将崩溃！”马上，在我终于得到nomethoderror和backtrace之前，似乎没有发生20多岁左右。

起初，我认为这可能是“你的意思是”宝石，所以我在命令行上关闭了 - did_you_mean，这关闭了“你的意思是”建议，但是没有什么可以加快回溯。

有趣的是，这仅适用于Nomethoderror。

如果我引起其他例外，例如：

puts "about to crash!"
a = 3/0

那时我会立即看到回溯。

甚至使事情变得更奇怪，如果我在“即将崩溃”之后中断过程！ （例如Unix上的Ctrl-C），然后我立即获得了Nomethoderror，它是回溯。因此，它具有信息 - 但是Ruby可能会试图清理某些东西，这只会在Nomethoderror上清理？

信息：Ruby 2.7.0

OS：Centos Linux版本7.5.1804

更新 - 到目前为止响应： 每个人似乎都在关注返回和分析红宝石代码。

除了在那里没有放缓。在减速过程中没有执行的红宝石代码行。在此之前的所有线路，“在回溯”中已经执行，并且在一秒钟左右的时间内。然后，系统悬挂在位置和nomethoderror之间。两者之间都没有Ruby代码，因此任何正在查看Ruby脚本中编写的代码的探险器都不会有帮助。放缓是Ruby的内部内容，并且不在我的代码中，除非我对正在发生的事情感到非常困惑。

非常清楚：

Line 10042:    puts "HERE"                  # Happens at ~1s
Line 10043:    Array.new().inspekt          # Happens at ~20-30s

这些行之间没有代码。在10042行执行之前，20-30不会在任何代码中发生，因此对没有帮助的分析。

我 do 还有其他暂停的纤维。但是这里没有代码能屈服。当击中异常时，是否有一些奇怪的内置收益代码试图运行其他（暂停）纤维？我想不出您想要这种行为的原因，以及它会造成灾难性的许多原因，但我想不出会引起这个问题的其他任何东西（这也可以用Ctrl-C杀死！ ）

Answer 1

我终于弄清楚了这个问题。

问题在于，Nomethoderror将使用Inspect，这将检查接收器的所有实例变量到Nomethoderror。

由于我正在编写一个相当大的程序，其中包含大量数据，因此我的许多顶级对象需要大量时间来计算“ Inspect”字符串。

有趣的是，如果您“ ctrl-c” nomethoderror，它将停止尝试构建检查字符串并仅使用类名称。我觉得其他实例试图构建检查字符串，并将在同一位置出现，打印出简单的nomethoderror，对幕后发生的事情（和失败）都不知道。

解决方案非常简单，我可以定义“检查”以使我的所有对象更合理。另一个选项是在nomethoderror中重新定义“详细信息”，以便在计算消息之前暂时重新定义错误的接收器“ to_s”的“检查”方法。对于具有相同类型的问题的其他例外，这可能会被概括，但我目前仅在Nomethoderror上看到它。

代码在下面 - 考虑到我对Singleton_classes的理解（缺乏）范围，我可能会做一些不太正确的事情，但是在各种测试中似乎都可以正常工作。请注意，仅当接收器明确定义to_s时，才能进行解决方法 - 这是该方法的第四行中的检查。这样会错过例如，例如，您继承了一堂课而不要重新定义to_s，因此您可能需要将其删除以为您的代码删除。 YMMV。

class NoMethodError
  def detailed_message(*a,**k)
    # Does the object *have* a to_s?  It could be unbound?
    return super(*a,**k) unless receiver.respond_to?(:to_s)
    # Does the object actually define to_s (itself)?
    return super(*a,**k) unless receiver.method(:to_s).owner == receiver.class

    # Save the old inspect
    oldInspect = receiver.respond_to?(:inspect) ? receiver.method(:inspect) : nil

    # Redefine inspect to call to_s
    receiver.define_singleton_method(:inspect) do; to_s; end

    # Get the detailed_message with to_s
    gotMessage = super(*a,**k)

    # Restore the inspect method
    if oldInspect
      receiver.define_singleton_method(:inspect, oldInspect)
    else
      # I think we could have just done this one...
      receiver.singleton_class.remove_method(:inspect)
    end

    # Return message
    gotMessage
  end
end

Answer 2

我会尝试在那里调试完整的回溯，以查看我

begin
  puts "about to crash!"
  Array.new().inspekt
rescue => e
  puts e.backtrace
  raise # raise anyway
end

在我的情况下实际发生的事情，我会使用Ruby 2.6.3和IRB进行20行回溯通过修改backtrace的每个文件并在每个步骤打印时间来测量每个运行时，请调试YAY！