I wonder if this API allow will foster a big movement to track down all the performance-hungry calls in say, Rails, and help the framework move forward in terms of efficiency. This is really a welcome addition anyway.
Rewritten in longer form, assuming I've made no mistakes, the two versions are equivalent to...
if params[:user_id].present?
if !@owner
@owner = User.find_by_login(params[:user_id])
end
end
vs
if !@owner
if params[:user_id].present?
@owner = User.find_by_login(params[:user_id])
end
end
Checking the member variable truthiness is presumably faster than a dictionary lookup followed by a call to "present?". As @owner is probably frequently/always true after the first call (it will be unless find_by_login returns false/nil/? or another method resets @owner, given the same instance), this leads to fewer dictionary lookups and present? calls, resulting in a performance increase.
EDIT: Well that was an amusing spam of simultaneous answers.
Assignment has higher precedence than if, so the line originally would have evaluated as:
(@owner ||= User.find_by_login(params[:user_id])) if params[:user_id].present?
Thus always testing the if, and then conditionally setting @owner. The new line checks the existence of @owner before evaluating the if by using parens to set precedence.
My theory is that it takes both a certain amount of pressure to create those tools, a certain amount of expertise and a certain amount of tooling available from the language. Due to being old, Perl has all of these and in Devel::NYTProf has a more than excellent profiler that goes beyond line, into statement level. See for example these profiling runs created with it: https://dl.dropboxusercontent.com/u/10190786/ppi_bench.zip
Comments
I wonder if this API allow will foster a big movement to track down all the performance-hungry calls in say, Rails, and help the framework move forward in terms of efficiency. This is really a welcome addition anyway.
I think TRWTF here is that checking for (query string?) parameter existence runs a regexp...
Some of us like to pre-divine a world devoid of bugs and silliness, others like to provide us with tooling to track stuff down
So, I'm a Ruby neophyte. Why did adding parenthesis speed that line up so much?
Rewritten in longer form, assuming I've made no mistakes, the two versions are equivalent to...
vs Checking the member variable truthiness is presumably faster than a dictionary lookup followed by a call to "present?". As @owner is probably frequently/always true after the first call (it will be unless find_by_login returns false/nil/? or another method resets @owner, given the same instance), this leads to fewer dictionary lookups and present? calls, resulting in a performance increase.EDIT: Well that was an amusing spam of simultaneous answers.
I don't write Ruby, but it's close enough to Perl that i can tell you. Precedence is the reason.
The first line with more explicit precedence is this:
The second line is this: In other words, the first version always ran the present? method, while the second version only did so if @owner was false.I haven't done too much Ruby myself, but the line looks sufficiently Perl like I believe the subtle change converted the first line (rolled out) from:
(excusing my Perl-Ruby mashup)
to: Now the call params[:user_id].present is only made if @owner lacks a value.Assignment has higher precedence than if, so the line originally would have evaluated as:
Thus always testing the if, and then conditionally setting @owner. The new line checks the existence of @owner before evaluating the if by using parens to set precedence.@owner ||= User.find_by_login(params[:user_id]) if params[:user_id].present? means:
@owner ||= (User.find_by_login(params[:user_id]) if params[:user_id].present?) means: So everytime someone called owner() to get the owner of a repo, the regex was checkedWhy is line level profiling so non-existent for dynamic languages? Function level just doesn't cut it, esp. w/ the zillions of monkey patches in Ruby.
Wait, what about stackprof rb-lineprof flamegraph rack-mini-profiler
My theory is that it takes both a certain amount of pressure to create those tools, a certain amount of expertise and a certain amount of tooling available from the language. Due to being old, Perl has all of these and in Devel::NYTProf has a more than excellent profiler that goes beyond line, into statement level. See for example these profiling runs created with it: https://dl.dropboxusercontent.com/u/10190786/ppi_bench.zip
It isn't. As usual the answer is LuaJIT (sorry, I am a fanboy, got to admit it): http://permalink.gmane.org/gmane.comp.lang.lua.luajit/3413
I was just looking at phpdbg and xdebug yesterday, and they do it, iirc :) so, not impossible, but Ruby does do more stuff dynamically.
At first I didn't realize OP was a GitHub employee and thought he was munging his company's GHE appliance :o
Cool read!