00:00:09.500
So this talk is titled '3x Rails,' but what does this title mean? This talk is about speeding up the Rails framework. I'm sorry I failed to bring something like a magical patch that makes things three times faster. I kind of planned to do this on stage, but instead, I’d like to discuss some possibilities or points of view. Again, what does the title '3x' mean? Actually, this title is inspired by Mats, you know, dad Ruby, who stated at RubyConf last year that he promised Ruby 3.0 would be three times faster than Ruby 2.
00:00:56.699
So, what's happening? It turns out that it’s quite easy to make Ruby on Rails three times faster. We just need to avoid performance regressions in the Rails side and let Ruby 3 handle the execution, which should naturally make Rails applications three times faster. Anyway, my name is Akira Matsuda. I work on various open-source projects, including the Ruby language and the Rails framework.
00:01:17.880
I also authored and maintain several gem libraries, like CommonRuby, ActiveDecorator, and others. Additionally, I run a local Ruby user group called 'Ruby Kaigi' in Tokyo, which was established in 2008. We meet every Ruby Tuesday, and so far, we have organized 356 meetups. We have many cool members from more than 30 different countries, making it quite a diverse group.
00:02:06.060
We welcome visitors from anywhere, so if you’re interested in joining our user group when you're in Tokyo, please contact me. I'm also organizing a Ruby conference in Japan called 'Ruby Kaigi.' It aims to be the most technical Ruby conference focused on the Ruby language itself.
00:02:34.790
This year, we are having another Kaigi in September in Kyoto. Please note that the conference is not in Tokyo this year; it's in Kyoto, the ancient capital of Japan, which is home to many historical temples, shrines, and gardens.
00:03:02.580
I think Kyoto is the most beautiful city in Japan, so if you haven't had the chance to visit before, I highly recommend attending this year’s conference. The venue looks amazing, featuring a beautiful Japanese garden. We are already selling tickets and the Call for Proposals (CFP) is open, so please check out the official website for more information.
00:03:48.870
Let’s begin the actual talk. As I mentioned earlier, this talk focuses on speeding up the Rails framework, not just your Rails applications. To speed things up, we first need to understand its speed metrics. To measure performance, we usually use benchmarking tools, such as Benchmark::IPS or Ruby’s built-in benchmark library. I prefer Benchmark::IPS because, for example, if you want to measure the performance of your Rails application, you can create a monkey patch to benchmark specific method calls.
00:06:21.380
This approach works by running the request multiple times, although I understand that it's not the best idea as it can produce variations in the score. This way, we benchmark only the Rails part and avoid any browser-related factors. The key question then is: how can we improve that score? One of my practical trials pertains to Ruby’s garbage collection (GC) because everyone knows Ruby GC can be slow. I believe stopping the GC will improve our performance significantly, potentially by 30%.
00:09:01.050
In this case, I used GC.stat calls to observe GC behavior. For instance, we can see reports showing how many iterations occur over a certain time frame. I found that during my benchmark, GC added about 10% overhead instead of the anticipated 30%. This shows that Ruby's GC has recently improved, which is encouraging.
00:10:21.940
Furthermore, with Ruby 2.3, we have new features that can enhance performance, particularly regarding string handling. Strings in Rails used to be a significant concern for the community, especially with regards to inefficient memory usage. I proposed a Ruby magic comment to freeze all string literals without affecting the code's clarity. This was introduced in Ruby 2.3, which could help achieve small performance gains.
00:12:31.660
Moreover, it’s common to think that Ruby is slow because it’s a scripting language and has to parse and compile code every time it runs. However, Ruby 3 introduces features that allow pre-compiling Ruby code into binaries, which can improve load time. I'm not going to delve into this too much since Koichi will cover it in more detail in his talk tomorrow.
00:14:52.440
Next, let's discuss which parts of a simple Rails application are typically slow. It's essential to profile your application to measure performance effectively. We can use profiling software like StackProf or other tools that many might already be familiar with. These tools allow you to dig deeper, and we also have the built-in TracePoint library to help count the number of method calls.
00:16:25.600
As for performance bottlenecks, one area that stands out is Action View, which has some inherent performance issues. The rendering process, for example, involves looking up and compiling templates, which can slow things down.
00:19:05.590
The current template lookup implementation involves calling directory glob for each request, which can become inefficient. I’ve proposed an optimized resolver that caches all template filenames in memory instead of hitting the filesystem for every request. Benchmarks show that this new implementation is significantly faster than the default resolver.
00:22:26.600
Another issue is how Rails handles rendering partials. Each partial can create a new buffer, which can slow down rendering when not necessary. We can rework the render method to optimize for cases where we don’t need a new view context. There’s also potential for sending full path filenames to the render call, allowing the template resolver to skip redundant lookups.
00:31:47.750
Additionally, I have considered enhancing performance through C extensions for certain parts of Rails. Shared code for evaluating how fast parts of Rails can go involves examining non-essential features and ensuring that they don't drag performance down. When thinking about optimal performance, we should focus on memory usage and consider removing unnecessary features from the core classes used like Active Record, which builds many temporary objects.
00:39:09.370
We can potentially construct SQL strings directly from simple queries to avoid overhead with unnecessary Active Record instances. In conclusion, performance bottlenecks vary between applications, and Rails could benefit from increased flexibility to address specific performance needs. Adapting Rails to be more modular, similar to Merb, could help introduce these kinds of optimizations. Thank you for your attention.
