How do I get ruby-prof to ignore Ruby core / standard library / gem methods?
Asked Answered
M

2

7

I'm new to Ruby profiling, and it seems like ruby-prof is a popular choice. I just installed the gem and invoked my program:

ruby-prof ./my-prog.rb

However, the output is incredibly verbose, because profiling data for all the Ruby core and standard library methods, and other gems are included. For example, the top three lines are:

8.79      0.011     0.010     0.000     0.001     3343  *String#% 
7.28      0.078     0.009     0.000     0.069     2068  *Array#each 
4.93      0.038     0.006     0.000     0.032     1098  *Array#map 

That's not remotely useful information for me, since I already know that my program deals with Strings and Arrays a lot, and presumably those classes have already had the hell optimised out of them. I only care about the hotspots in my code.

I tried some of the other printer modes, e.g. -p graph_html and -p call_stack, but they all have the same problem.

I see that ruby-prof supports some method elimination and simplification:

-x, --exclude regexp             exclude methods by regexp (see method elimination)
-X, --exclude-file file          exclude methods by regexp listed in file (see method elimination)
    --exclude-common-cycles      make common iterators like Integer#times appear inlined
    --exclude-common-callbacks   make common callbacks invocations like Integer#times appear

but there doesn't seem to be any obvious way to get what I really want, which is profiling data for my code only, i.e. with time elapsed inside code from Ruby core / stdlib, and other gems only being counted as time elapsed inside my code.

Once I can see that my code has a method foo which is a performance bottleneck due to being called thousands of times and not performing well, then and only do I want to see the breakdown of time elapsed between my code and core/library code called within that particular method.

I can't understand why this isn't a standard feature, since I would expect that it's what everyone wants to do: profile your own code first, and then once you've run out of things to optimize, potentially start optimizing the gems you use and maybe even Ruby core / stdlib. What am I missing?

Mord answered 11/8, 2013 at 11:57 Comment(0)
B
2

I agree this is a big problem with ruby-prof. I've tended to prefer perftools.rb. It integrates with gperftools and it supports various focus and ignore options, along with graphical reports which are superior for quickly understanding hotspots and their call trees.

With ruby-prof, you might also try outputting KCacheGrind format and using the KCacheGrind Viewer for analysis. It has a number of visualization modes and facilitates ad hoc filtering and exploration of results.

Benzel answered 11/8, 2013 at 16:38 Comment(0)
H
0

You may want to profile and benchmark via tests. Minitest allows for this in their testing framework. That way you can concentrate on specific behaviors to get your timings.

Available in Ruby 2.0 or as a Gem for Ruby 1.9 and lower.

As far as profiling in the same way, require 'profile' and use it for those same tests.

This blog post details how to do this, I don't believe it has changed greatly.

Hu answered 11/8, 2013 at 12:51 Comment(2)
Thanks for the answer, but my test suite is already written in RSpec. I'll give profile a go but that blog seems to show it suffering from exactly the same problem of library methods polluting the results.Mord
Yeah, it definitely isn't an exact match for an answer, but might get you closer. And as far as using RSpec, seeing how they did it in minitest may give you some clues. RSpec is just Ruby, open it up and modify it... and maybe submit a feature!Hu

© 2022 - 2024 — McMap. All rights reserved.