DEV Community: Yago Santos

Yet Another Post About Ruby Blocks

Yago Santos — Sat, 23 Jul 2022 20:46:00 +0000

If you have been programming in Ruby for awhile now, you have likely already used built-in methods such as #each, #select, and #map. Despite of what everyone says about Ruby magic, there's nothing special with the way those methods work.

Those methods are usually called on collections, such as Arrays and Hashes, either using an inline block (code wrapped by curly braces) or a multiline block (code wrapped between do and end).

How do Blocks Work?

We frequently associate blocks of code with methods that are available to us through the Enumerable module. Please take a look at the example below:

Inline Block:

[1, 2, 3, 4, 5].select { |number| number.even? }

> [2, 4]

Multiline Block:

[1, 2, 3, 4, 5].select do |number|
  number.odd?
end

> [1, 3, 5]

In order to fully understand how blocks work, it's necessary that we learn how to create our own custom blocks to grasp the nitty-gritty details!

Yielding Control to a Block

Any method in Ruby can be associated to a block, but what determines if that block is going to be invoked or not during the method's execution is the special keyword yield.

roll_die { |number| puts "You rolled #{number}" }

How could we implement that method?

def roll_die
  puts "Method is executing..."
  random_number = rand(1..6)
  yield(random_number)
  puts "Method is done!"
end

Therefore, once we invoke the roll_die method with the associated block it'll print the following lines to the console:

> "Method is executing..."
> "You rolled 3"
> "Method is done!"

What yield is doing is "pausing" the roll_die method's excution and passing the control over to the block that is associated with it. Plus, it's also passing the random_number parameter as a block parameter to the block!

A curiosity about blocks is that once its done executing it returns the last computed line of code as the final result! Wait a second...what does that mean, though?

It means that we could have done something like this instead:

Rearranging the code in the roll_die method:

def roll_die
  puts "Method is executing..."
  random_number = rand(1..6)
  result = yield(random_number)
  puts "You rolled #{result}"
  puts "Method is done!"
end

Rearranging the code block associated to the roll_die method:

roll_die do |number|
  puts "Rolling the die..."
  number
end

In that new arrangement above, the random number is being returned by yield and assigned to the variable result in the roll_die method!

> "Method is executing..."
> "Rolling the die..."
> "You rolled 1"
> "Method is done!"

Caveats About Ruby Blocks

If you have read this far, you are likely wondering what happens if we try to yield but there isn't an associated block to pass over control to. Well, for those scenarios we can use the block_given? method. Check out the example below:

Defining the greeting(name) method:

def greeting(name)
  if block_given?
    yield(name)
  else
    "No block was given."
  end
end

Associating the greeting(name) method with a block:

greeting(name) { |name| "Hello,  #{name}!" }

Now, there are 2 different ways to invoke the greeting(name) method:

# First way
greeting("Mary") { |name| "Hello,  #{name}!" }

> "Hello,  #{name}!"

# Second way
greeting("John")

> "No block was given."

Another curiosity is around the number of parameters passed to yield, which in turn are sent as block parameters to your block. Are they enforced/requested by Ruby or not? Give it a try using irb - you'll be surprised with the result!

Please do let me know if you have any questions and/or suggestions in the comments below!

Yet Another Post About N + 1 Queries

Yago Santos — Wed, 13 Jul 2022 03:16:00 +0000

The N + 1 query problem is a common performance bottleneck found in queries that are written using an ORM (Object-Relational Mapping) tool, such as ActiveRecord.

The problem arises when N queries have to be executed, for each association, in addition to the first one made to fetch all the associated records.

For instance, if we had the following relationship between User and Appointment models

# app/models/user.rb
class User < ApplicationRecord
 has_many :appointments
end

# app/models/appointment.rb
class Appointment < ApplicationRecord
 belongs_to :user
end

and executed the query below in our code

Appointment.all.limit(5).each do |appointment|
 puts "#{appointment.user.name} has an appointment at #{appointment.date}"
end

this is what we would see in our rails console:

Appointment Load (0.5ms)  SELECT "appointments".* FROM "appointments" LIMIT ?  [["LIMIT", 5]]
 User Load (0.1ms)  SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT ?  [["id", 1], ["LIMIT", 1]]
 User Load (0.1ms)  SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT ?  [["id", 3], ["LIMIT", 1]]
 User Load (0.1ms)  SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT ?  [["id", 5], ["LIMIT", 1]]
 User Load (0.1ms)  SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT ?  [["id", 7], ["LIMIT", 1]]
 User Load (0.1ms)  SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT ?  [["id", 9], ["LIMIT", 1]]

The query above seems to be harmless, but imagine we had to load 1,000 appointments! We'd need to hit the database 1 time (to grab all appointments) plus 1,000 times (to grab each appointment's user), totalling 1,001 queries. In technical terms, the results are being lazily loaded, meaning that the "N" consecutive queries will be made as they are requested in appointment.user.name.

How to Reduce the Number of Independent Database Queries?

A possible solution for this is to use .includes, which will eager load the query result, meaning that the related associations (parent and children) will be loaded all at once through only a few queries.

For example, if we run the following code in the console

Appointment.includes(:user).limit(5).each do |appointment|
 puts "#{appointment.user.name} has an appointment at #{appointment.date}"
end

this is what we would get back:

Appointment Load (0.2ms)  SELECT "appointments".* FROM "appointments" LIMIT ?  [["LIMIT", 5]]
 User Load (0.3ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)  [["id", 1], ["id", 3], ["id", 5], ["id", 7], ["id", 9]]

As we can see from the result above, only 2 queries are being ran against the database, instead of 6 when the results were being lazily loaded.

Backing it Up with Data!

At this point you may be wondering "Okay, enough talking! Where is the data showing that using .includes actually improves query performance?".

When attempting to lazy load 100 users' appointments, we get the results below in miliseconds:

user     system      total        real
0.101984   0.096377   0.198361 (  0.761556)

On the other hand, when we try eager loading the same 100 records, we get faster execution times:

user     system      total        real
0.026250   0.010747   0.036997 (  0.078877)

If we take in consideration the total time, which is a sum of the time spent executing the code (user) plus the time spent in the kernel (system), eager loading the records is 5.36 times faster!

You can read more about Ruby's benchmark module here.

How to Identify N + 1 Queries in an Application

In order to find all those N + 1 queries that are slowing down in your application, the community recommends using the Bullet gem.