FIX YOUR CODE

In this blog post, I am going to continue what I started earlier. In other terms, I keep watching Ruby & Rails related conferences videos on Confreaks, and summarizing them on my blog. Today, I watched a very interesting talk given by Aaron Patterson (aka @tenderlove) called ZOMG Why is this code so slow?. Aaron is the father of Nokogiry, and he is basically  the only one who is contributing both to Ruby and Rails (where he is the 4th top contributor)! He is also very fun to listen to, very comic but serious about the stuff he is talking about. (he actually reminds me of Scott Hanselman in the .NET world).

So the goal of this talk was to talk about the performance improvements that he made on ActiveRecord while rewriting ARel. Or no, wait! It was about the work he has done on ARel while improving the performances on ActiveRecord. Seems confusing? Actually, it is not. The goal of his talk was to explain how he fixed the performance issues on Rails 3.0.  Rails 3.0 has (or had) performance issues? Turns out, yes! In fact, ActiveRecord was 5 times slower than Rails 2.3! Now things are doing better thanks to his work, but what did he do exactly? Let’s go into that! Summary starts…

What’s ARel?

• ARel is a Relational Algebra Library. It can handle an AST (Abstract Syntax Tree) and turns into something else. In the context of its integration within ActiveRecord, it turns that AST into a SQL statement.

Are the performance issues related to Ruby?

• Aaron mentions than even if Ruby is not a super fast language (at least comparing to compiled languages like C), usually the slow is linked to poor code.

When should we make our code faster?

• When it is not fast enough.

How do we know that it isn’t fast enough?

• When people start noticing it.

What is the basic thing that we need to do when working on performance?

• Measuring and benchmarking. In fact measurement is paramount, because it allows us to know exactly how much faster, a chunk of code became after our modifications.

But, what do we need to measure?

• For the ActiveRecord performance issues, Aaron started thinking about the different stack layers that get called when a user makes a request such as Post.find(id). The stack goes like this:

1. Post.find(id)

2. ARel

3. find_by_sql(id)

4. execute()

5. log()

At somepoint, Aaron decided to focus on the 3 top level layers (from find_by_sql to log). He needed to run some benchmarks to know exactly where the performance issues were really occuring. We will get back to that later.

What are the two things that we should optimize for when dealing with performance?

• Time and space;

What do we need to reduce in our to gain in performance?

• Method calls.

• Branching and looping.

• Objects (memory consumption).

And turns out that when writing a clean code, the things to reduce are exactly the same. Therefore Performant Code == Clean Code.

What tools do we have to run benchmarks?

• The Ruby benchmark library, which can be used like this:

require 'benchmark'

def fib n
  a = 0
  b = 1
  n.times { a, b = b, a + b}
  a
end

Benchmark.bm(7) do |x|
  x.report("fib") do 
    3000.times do |i|
      fib(1000)
    end
  end
end

Which gives the following results:

• However this benchmark is not very helpful. It doesn’t give information about how this fibonacci sequence was generated. We need to benchmark through an increasing number of iterations in order to know about the nature of the algorithm that has been used.

For example:

require 'benchmark'

def fib n
  a = 0
  b = 1
  n.times { a, b = b, a + b}
  a
end

Benchmark.bm(10) do |x|
  [1, 10, 100, 1000, 10000].each do |n|
    x.report("fib #{n}") do
      n.times { fib(1000) }
    end
  end
end

• This has the ability to give us the information that the algorithm runs in a linear time.

• We also have another tool for benchmarking which is called Minitest/benchmark.

What does minitest add to the game?

Minitest is nice in the sense where it allows us to assert that a given algorithm occurs within a certain class of complexity. For instance we could assert that an algorithms runs in linear time, if someone changes it in the way that it woul run in polynomial time then the assert would fail.

From the previous stack, where did the change happen?

After running benchmarks using the previous tools and after plotting the results, Aaron realized that the changes occured at the log() method.

What do we do then?

• We need to run method call analysis. To do that we can use Perftools which is a sampling profiler. We can also use Ruby-prof to see the actual number of method calls.

• In Rails 2.3  2000 method calls of Time#now and Time#allocate were made for every 1000 iterations Vs 4000 in Rails 3.0 beta.

• After fixing this, things were better but still 2 times slower.

What to do then?

Given that the find_by_sql part didn’t really change between the two version of Rails, ARel was the one that needed to be improved!

First strategy: make superficial improvements!

• Superficial improvements are useful when we have a limited domain and system knowledge. It allows us to see the results quickly, but we don’t get so much benefits for the time put into it. The superficial improvements that were made are the following:

• attr_ accessors*

def some_attribute
   @some_attribute
end
# vs
attr_reader :some_attribute 

• The attr_reader is much faster than the method form. The reason behind this is that the way Ruby is built, is that it looks to an AST of code to execute. The C code for the method form is much longer. This code uses vm_setup_method which does:

1. Check for stack overflow.

2. Pushing a stack frame.

3. Copying arguments.

• #ProTip: if we need to write the accessor method? we can write an alias like this:

class Foo
  attr_reader :some_attribute
  alias :some_attribute? :some_attribute
end

• Hash Vs Inject

Rubyists tend to write the following code:

some_list.inject({}) do |hash, val|
  hash[val] = some_transform(val)
  hash 
end

This could be instead written like this:

values = some_list.map { |val|
  [val, some_transform(val)]
}
Hash[values]

Benchmarking these two give the following result:

• inject is slower than hash + map. The reason is that people are using it wrong, we should use injectonly when one calculation depends on a previous one.

• This is a better usage for inject():

%w{
  Foo
  Bar
  Baz
}.inject(Object) { |klass, string|
  klass.const_get(string.to_sym)
}

• Proc Activation

lambda {...} # vs 
class Callable
  def call; .. end
end

• A lambda takes much more longer than a method call does. The reason is because the lambda needs to remember its context.  So Aaron advises us to use lambda only if we care about using a lambda not just because it responds to call.

• define method

class Foo
  def foo; end
  define_method :bar do; end
  class_eval %{ def baz; end }
end

• class_eval is about the same speed as the normal method. define method is much longer. define method uses a bloc.

• Explicit bloc parameters

class Foo
  def explicit & block
    yield
  end

  def implicit
    yield
  end
end

• Explicit is slower. We are creating a Proc Object and we are paying its cost (garbage collecting this Proc object). The following is a pattern we should follow:

def sometimes_block
  if block_given?
    Proc.new.call
  end
end
sometimes_block { puts "hi" }
sometimes_block

• Symbol to Proc

@list.map(&:to_i)
# vs
@list.map { |x| x.to_i }

- Symbol to Proc is much slower than just using a bloc. But in 1.9 that’s not true. So we need to know who we target (know your audience).

• Return value caching

def some_method
  @some_method ||= some_expensive_op
end

• Here we have extra method calls so it should be avoided as much as possible. Can the caller cache?

• At the end of these superficial improvements, the performance were better but not as good as they were on Rails 2.3. Aaron needed to go deeper!- After deeper inspections, he noticed that a lot of time was spent at Class#new. A lof time at garbage_collector which means that we create a lot of objects and throw them away.

- He did some Data Structure Analysis (using Graphviz), and he implemented a visitor pattern. The reason for using the visitor pattern is to be able to examine these data structures from the outside.

• He discovered that the SQL statements generation on ARel had a complexity of n². He knew that SQL generation could be done at a linear time so he decided to rewrite ARel. This decision was supported by the following facts:

1. There is a clear solution.

2. Tests are numerous.

3. Public API is limited.

After 6 weeks of work, the results were encoruaging:

• SQL statement generation was done at linear time.

• ARel is now 2 times faster.

• Adapter specific code is DRY.

He also implemented a new feature on ActiveRecord. Run the following : Model.where("id == xxx").to_dot and admire the graph that is generated and that shows the relation between all the calls that are made .

He finally finishes the talk by these two words of wisdom:

- We emphasize the art of code, but we should not forget the science.

- Learn the specific but embrace the generic.

I could not agree more!

As you can see, this talk was very informative and contained many tips about how we should approach performance problems. He introduced some benchmarking tools and explained the process by which he went through to make Rails 3.0 beta as fast as Rails 2.3.