我有一堆运行时间太长的rspec测试。我试图弄清楚瓶颈在哪里，合理的起点是使用标准库配置文件库。在这种特殊情况下，JRuby 1.5.2正在执行。以下是在我的规范中嵌入配置文件库后的输出：
% cumulative self self total
time seconds seconds calls ms/call ms/call name
0.37 0.37 0.37 69 5.33 5.33 #<Class:#<Object:0x99b2a1d>>#include
0.01 0.38 0.01 208 0.06 0.06 String#fast_xs
0.00 98.99 0.00 1 0.00 98987.00 #toplevel
我需要调查为什么要对String＃fast_xs进行208次调用，但这里真正的问题是#toplevel究竟发生了什么？在那里的某些东西上花费了98987.00ms的延迟，我需要更细粒度的方式来查看故障，以了解我可以在我的规范测试中改变什么以加快速度。
答案 0 :(得分：2)
有这么多问题。显示了一些配置文件输出，问题是：“发生了什么？”
没有必要对配置文件输出进行拼图。你可以find the problem(s) right away。他们花的时间越多，就越容易找到。
任何处理自助时间，每次通话时间，通话计数等的事情都会陷入performance myths的陷阱。
补充：例如
自我时间（独家）基于这样一个前提，即你可以浪费时间的唯一方法是不调用函数。当不必要地调用函数时，您想要查找和删除函数，或者如果不必要地执行IO，它不会在自我时间中显示。如果仅在程序解除阻塞时采集样本，则IO和其他阻塞时间根本不会显示。
ms-per-call（包括），乘以函数的调用次数除以总时间，得出函数负责的时间分数。只有这三个数字中的两个，你无法分辨这个功能是否花费了太多时间。
如果你能判断一个函数是否负责很长一段时间，你仍然需要在其中找到负责时间的行。 如果探查器就像你关心的唯一单位就是功能，那么你仍然在做侦探工作。
答案 1 :(得分：0)
你有多少次测试？每个RSpec测试都会重新加载整个Rails环境，因此如果您有大量测试，那么开销最有可能来自于此。您可以查看运行测试时只加载环境一次的Spork测试服务器。
使用Spork的Ruby on Rails教程书recommends如果您正在进行大量测试并且遇到慢速测试的问题。
答案 2 :(得分：0)
有jruby-prof宝石可能对你有帮助。用于MRI的ruby-prof宝石也可以提供出色的帮助。