Ruby 2.1: Profiling Ruby

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

@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

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.

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.

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.

>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

I was just looking at phpdbg and xdebug yesterday, and they do it, iirc :) so, not impossible, but Ruby does do more stuff dynamically.

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