I’m seeing a lot of disappointment about the speed of Ruby 3 out there. I think there are a lot of reasons for that, and I think they’re worth looking at.

So: why wasn’t Ruby 3 faster? Did it break its promise? (Spoiler: I don’t think so, but I understand why some people do.)

If you’ve been following me awhile, you know that I was hired by AppFolio years ago to measure Ruby 3’s performance, especially on Rails. This has been a long trip. And that very first project is finally over: Ruby 3 exists and I can check its final, released Rails performance.

If you have been following along, the numbers in this post won’t surprise you. But it’s important to do the final measurement. If you haven’t been following, this will bring you up to date.

Ruby 3x3 is coming in about a month. One of its new concurrency primitives is Ractors, which used to be called “Guilds.” (The other new concurrency primitive is Autofibers.)

Ruby has a Global VM Lock (GVL), also called the Global Interpreter Lock (GIL), that prevents running Ruby code in more than one thread at once. So Ruby threads are great for I/O like waiting on files or databases. And they’re great for cases where a C extension can keep calculating in a background thread while a foreground thread runs Ruby. But you can’t do calculations in Ruby in more than one thread at once within the same process.

At least not until Ruby 3 and not without Ractors.

Great! Now how fast is the current implementation of Ractors?

Do you ever look at the list of Amazon EC2 instance types?. Those are sizes of virtual machine you can rent to run your code on. Well, okay, they’re groups of sizes, since each one of those headings has a bunch of different sizes of VM…

So what type of EC2 instances should you run your Rails app on?

The answer is simpler than it looks.

Do you love numbers? I love numbers. Do you hate numbers? Skip to the bottom, there’s a nice summary paragraph. Do you really really love numbers? There are raw data dumps including all my intermediate results.

The new Ruby 3.0 preview is out! Woo-hoo!

If you’ve heard of me, you know performance is kinda my thing, especially Rails performance on large apps. I do other stuff too, but I got paid to do that for years (thanks, AppFolio!), so I’ve written a lot about it.

How does the new preview’s performance stack up on Rails? And how reliable are these numbers?

Here we continue with the series of articles where we talk about how minor adjustments in the code can lead to major performance improvements.

In this article we’ll focus on the use of ActiveRecord::Batches#find_each when it comes to iterations across a large number of records.

Some time ago we wrote a couple of Tips for Writing Fast Rails. It was about time we wrote part two so here it is!

Rails is a powerful framework. You can write a lot of features in a short period of time. In the process you can easily write code that performs poorly.

At OmbuLabs we like to maintain Ruby on Rails applications. In the process of maintaining them, adding features and fixing bugs, we like to improve the code and its performance (because we are good boy scouts!)

Here are some tips based on our experience.

Prefer where instead of select

When you are performing a lot of calculations, you should load as little as possible into memory. Always prefer a SQL query vs. an object’s method call.