5 ms·

Ruby 2.1: Profiling Ruby

• wrl 13y ago
  So, I'm a Ruby neophyte. Why did adding parenthesis speed that line up so much?
  • jbverschoor 13y ago
    @owner ||= User.find_by_login(params[:user_id]) if params[:user_id].present? means: if params[:user_id].present? if not @owner @owner = User.find_by_login(params[:user_id]) end end @owner ||= (User.find_by_login(params[:user_id]) if params[:user_id].present?) means: if not @owner if params[:user_id].present? @owner = User.find_by_login(params[:user_id]) end end So everytime someone called owner() to get the owner of a repo, the regex was checked
  • Moto7451 13y ago
    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) if (params[:user_id].present){ if (!@owner){ @owner = User.find_by_login(params[:user_id]); } } to: if (!@owner){ if (params[:user_id].present){ @owner = User.find_by_login(params[:user_id]); } } Now the call params[:user_id].present is only made if @owner lacks a value.
  • Mithaldu 13y ago
    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: if( params[:user_id].present?) { @owner ||= User.find_by_login(params[:user_id]) } The second line is this: @owner ||= ( User.find_by_login(params[:user_id]) if params[:user_id].present? ) In other words, the first version always ran the present? method, while the second version only did so if @owner was false.
  • deleted 13y ago
    [deleted]
  • MaulingMonkey 13y ago
    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.
  • stock_toaster 13y ago
    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.
• akx 13y ago
  I think TRWTF here is that checking for (query string?) parameter existence runs a regexp...
  • sams99 13y ago
    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
• kbar13 13y ago
  At first I didn't realize OP was a GitHub employee and thought he was munging his company's GHE appliance :o Cool read!
• gazarsgo 13y ago
  Why 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.
  • copx 13y ago
    >Why is line level profiling so non-existent for dynamic languages? 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 http://permalink.gmane.org/gmane.comp.lang.lua.luajit/3413
  • girvo 13y ago
    I was just looking at phpdbg and xdebug yesterday, and they do it, iirc :) so, not impossible, but Ruby does do more stuff dynamically.
  • sams99 13y ago
    Wait, what about stackprof rb-lineprof flamegraph rack-mini-profiler
  • Mithaldu 13y ago
    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 https://dl.dropboxusercontent.com/u/10190786/ppi_bench.zip
• VeejayRampay 13y ago
  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.