How to Ignore Irrelevant Methods When Profiling Ruby Applications

Is it possible to ignore irrelevant methods when profiling ruby applications?

Version 0.9.0 of ruby-prof allows method elimination. For example, to eliminate Integer#times, use

result = RubyProf.stop
result.eliminate_methods!([/Integer#times/])

so that

def method_a
5.times {method_b}
end

will indicate the relationship between method_a and method_b directly.

Profiling Ruby Code

Lots of profilers are like that.
What you need to know is not where the program spends its time, but why. Any references on Dynamic Code Analysis?

ADDED: Here's how I find "bottlenecks" in my code. (I hate that word.)
Here's a list of reasons why.

It is perfectly natural to assume that to find "bottlenecks" you have to somehow do a lot of measuring.
It is so natural that nearly all profilers are based on it.

Actually, finding and measuring are not the same problem. Measuring is needed to see if what you found (and fixed) made a difference. Finding what to fix, to me, is more like debugging than measuring.

The simplest way to explain it is to start from an infinite, or nearly infinite loop. How do you find it? You pause it and look at the stack, right? because you know the problem is somewhere on the stack. You only need to pause it once, and then you need to study the code on the stack. Pause it a few times if you want to be sure you've found it.

Suppose the code only takes twice as long as necessary. That means when you pause it, there is a 50% chance you will see it doing the unnecessary thing. If you pause it and look at it 10 times, you will catch it in the act roughly 5 times. In fact, as soon as you see it doing something you can optimize on as few as 2 samples, you've found a "bottleneck". Fix it, measure the speedup, show it off, and repeat.

Even if your biggest problem is not very big, this method will eventually find it.
Also, there's a magnification phenomenon, where small problems become easier to find after you've removed larger ones. That allows you to keep going until the code is nearly optimal.

P.S. After you've done this, there may still be opportunities for speedup. For example, optimization algorithms can depend on numerical stability. Message-driven architectures can make it harder to trace why code is being executed. In real-time software, a performance problem may only happen occasionally, and be less easy to sample. This requires more cleverness. Falling back on just measuring doesn't do it.

Takes user input string and convert it to secret code from hash

Try something like this:

replace = {
"A" => "Z",
"B" => "Y",
"C" => "X",
"D" => "W",
"E" => "V",
"F" => "U",
"G" => "T",
"H" => "S",
"I" => "R",
"J" => "Q",
"K" => "P",
"L" => "O",
"M" => "N",
"N" => "M",
"O" => "L",
"P" => "K",
"Q" => "K",
"R" => "I",
"S" => "H",
"T" => "G",
"U" => "F",
"V" => "E",
"W" => "D",
"X" => "C",
"Y" => "B",
"Z" => "A"
}

puts "Time to decipher some code: "
input = gets.chomp.upcase

output = ""
input.each_char do |c|
output << replace[c]
end
puts output

What's the point of for x in y in Ruby?

The tutorialpoint page is correct, for is equivalent to each except for the scoping difference. Here's a demonstration:

arr = [1,2,3]
arr.each do |x|
last = x
end
last # NameError

vs.

arr = [1,2,3]
for x in arr
last = x
end
last #=> 3

If you want to make it work using each, you need to do last = nil before the loop. This is, as the link pointed out, because blocks start a new scope while for does not.

Note however that this rarely makes a practical difference and few people are even aware of it.

When people use for in ruby it's most often because that's what they're used to coming from other languages - not because of any differences between for and each.

Why exclude tests from gemspec files?

Besides holding arbitrary metadata about a gem, one important thing that the Gemspec does is tell Rubygems which files are needed to build your gem.

I think Bundler recommends excluding tests because they aren't functional code that is needed for your gem to be built or run. Including every test suite for every Gem in the Ruby universe would be expensive. There isn't a compelling reason you would need to access Omniauth's tests from within your app.

The tests are important, and that's why they were exist as part of the repository. They just aren't necessary in production, so they don't get wrapped up in the package you download from Rubygems.

As for .gitignore and .travis.yml you can exclude these on your own. I don't think the Bundler team was trying to think of every scenario, just the most likely ones.



Related Topics



Leave a reply



Submit