{"id":23643,"date":"2019-01-12T12:25:10","date_gmt":"2019-01-12T12:25:10","guid":{"rendered":"https:\/\/stackify.com\/?p=23643"},"modified":"2024-04-19T05:39:25","modified_gmt":"2024-04-19T05:39:25","slug":"ruby-performance-tuning","status":"publish","type":"post","link":"https:\/\/stackify.com\/ruby-performance-tuning\/","title":{"rendered":"Ruby Performance Tuning"},"content":{"rendered":"

There are many things to praise about the Ruby language: adherence to the object orientation paradigm, simplicity, elegance, and powerful meta-programming capabilities. Unfortunately, performance isn\u2019t top of mind when people think about the many qualities of the language.<\/p>\n

For years, people have been denouncing the Ruby programming language as slow. Is it? Sure, some people will spread a fair amount of FUD<\/a> around. That\u2019s the tech industry. But there\u2019s no denying that, at least in its main implementations, performance isn\u2019t the area where Ruby shines the most.<\/p>\n

In today\u2019s post, we will cover explanations for Ruby performance issues. Then we\u2019ll cover practical tips on what to do to improve the performance of your Ruby apps. Let\u2019s get started!<\/p>\n

<\/a>What can make Ruby code slow?<\/h3>\n

\"image-turtle\"<\/h2>\n

Ruby performance is sometimes slow, and since we\u2019re not happy with that, we must learn how to speed it up. To do that, we have to understand the causes of Ruby’s slowness. And that\u2019s what we will do in this section.<\/p>\n

Ruby has a high memory consumption. It\u2019s an inescapable feature of the language that stems from its design. Remember when I said earlier that one of the most often-celebrated aspects of Ruby is its loyalty to the object orientation paradigm? In Ruby, everything (or almost everything) is an object. This characteristic, in the opinion of many people including myself, makes for code that feels more predictable and consistent, causing fewer \u201cwhat the heck\u201d moments for the reader. They often call this \u201cthe principle of least astonishment,\u201d or PLA.<\/p>\n

But this characteristic\u00a0is also one cause of poor Ruby performance. Programs need extra memory to represent data\u2014even primitives like integers\u2014as objects.<\/p>\n

Finally, Ruby\u2019s GC (garbage collector<\/a>) isn\u2019t that great\u2014at least in versions before 2.1. The algorithm for Ruby\u2019s GC is \u201cmark and-sweep,\u201d which is the slowest algorithm for a garbage collector. It also has to stop the application during garbage collection. Double performance penalty!<\/p>\n

Ruby performance tuning: tips to fix common problems<\/h3>\n

\"fix-problem\"<\/h3>\n

Since you\u2019re reading a post called \u201cRuby performance tuning,\u201d I\u2019m sure you\u2019re looking forward to seeing performance tuning tips! That\u2019s what we will see in this section. We\u2019ll cover common Ruby performance problems a developer can face when writing Ruby code and what you can do to solve them\u2014or avoid them altogether.<\/p>\n

Read files line by line<\/h4>\n

Reading an entire file\u00a0at once can take a heavy toll on memory. Sure, the larger the file you\u2019re reading, the larger the amount of memory needed; even relatively small files can put a lot of pressure on your program\u2019s performance. And why is that? Simple: more often than not, reading the file is just the first step. After that, you\u2019ll most likely want to perform parsing to extract the data found in the file and do something useful with it. This will inevitably lead to the creation of additional objects, which takes more memory and exerts even more pressure on the GC.<\/p>\n

Let\u2019s see a quick example. Consider the following excerpt of code:<\/p>\n

require 'Date'\ncontent = File.open('dates.txt')\nyears = content.readlines.map {|line|line.split(\"\/\")[2].to_i}\nleap_years = years.count{|y|Date.leap?(y)}\nputs \"The file contains #{leap_years} dates in leap years.\"<\/code><\/pre>\n
This is a silly example, but should suffice for our needs. We have this file called \u201cdates.txt,\u201d which contains\u2014you guessed it!\u2014lots of dates.\u00a0And they\u2019re in the \u201cdd\/mm\/yyyy\u201d format, even though this isn\u2019t particularly relevant to the whole performance thing.<\/p>\n
The code loads the whole file to memory. Then we use the \u201creadlines\u201d method, which returns all the lines in the file as an array. After that, we map through each line, executing a code block that splits each line using the \u201c\/\u201d character as a separator. Then we retrieve the last part of the result\u2014which refers to the year\u2014and convert it to an integer number.<\/p>\n
It assigns the result of all of this to the \u201cyears\u201d variable. Finally, we use the \u201ccount\u201d method to determine how many of the years are leap ones, and we print that information.<\/p>\n
\"\"<\/p>\n
The code itself is simple, right? But think about it: why do we need to load the whole file in the memory before starting the process? The short answer is \u201cwe don\u2019t.\u201d Since we\u2019re doing the parsing and leap year verification on a line basis, we could\u2014and should\u2014retrieve the lines in the file one by one and then perform the parsing:<\/p>\n
file = File.open(\"dates.txt\", \"r\")\nwhile line = file.gets\n    year = line.split('\/')[2].to_i\n    if Date.leap? year then\n        leap_years += 1\n    end\nend<\/code><\/pre>\n
Even this version still has room for further Ruby performance tuning, but that can be an exercise for the reader.<\/p>\n
Change in place whenever possible<\/h4>\n
You already know Ruby, because of its design, allocates more memory. You\u2019ve also learned that Ruby\u2019s GC, particularly in the older versions, isn\u2019t that fast. To overcome this important roadblock to better Ruby performance, we must use strategies to save as much memory as possible.<\/p>\n
One strategy at your disposal amounts to changing objects in place. For changing an object, it\u2019s common for Ruby to have methods that come in two versions. One version returns a new object with the desired modification, keeping the original object unchanged. The other version changes the original object, thus avoiding the extra memory allocation. The method that changes the original object usually has the same name as the version that returns, plus an exclamation mark.<\/p>\n
Let\u2019s begin by covering strings. In scenarios where you won\u2019t need the original string after the modification, consider using\u00a0the versions that change in place. With strings, you should always be careful when concatenating them. To be honest, this is a common performance tuning tip for many languages, not just Ruby. The most used way of concatenating strings will create new objects in memory, which is what we\u2019re trying to avoid:<\/p>\n
message = \"I like\"\nmessage += \"Ruby\"<\/code><\/pre>\n
In\u00a0 situations like this, favor using the \u201c<<\u201d (append) method instead:<\/p>\n
message = \"I like\"\nmessage << \"Ruby\"<\/code><\/pre>\n
That way, Ruby won\u2019t create a new string object, and you\u2019ll avoid the extra memory allocation.<\/p>\n
Strings aren\u2019t the only objects that present this memory-saving opportunity. Arrays and hashes are also objects that\u00a0you can modify in place. The reasoning here is the same as with strings: change the objects in place for situations where you\u2019ll no longer need the original ones.<\/p>\n
Tune code that deals with iterators<\/h4>\n
Ruby iterators can be a source of bad performance because of their intrinsic characteristics. First, the object being iterated won\u2019t be garbage-collected until the\u00a0iterator\u00a0is done. The implications of this can be serious. Imagine you have a big list in memory and you\u2019re iterating over it. The whole list will stay in memory. Have no use for the items already traversed in the list? Too bad. They\u2019ll stay in memory just the same.<\/p>\n
Here\u2019s the second important point about iterators: they\u2019re methods. This is so they can create temporary objects. What does that mean? You guessed it. It means more pressure on our friend the garbage collector.<\/p>\n
Now we understand how iterators can harm Ruby performance, let\u2019s see tips to counter that problem.<\/p>\n
Free objects in collections while iterating over them<\/h5>\n
Suppose you have a large list of a certain object. You iterate over it and use each item in some calculation, discarding the list after you\u2019re done. It would be better to use a while loop and remove elements from the list as soon as they\u2019re processed.<\/p>\n
\"\"<\/p>\n
There might be\u00a0negative effects of list modification inside the loop, but you shouldn\u2019t worry about them. GC time savings will outweigh those effects if you process lots of objects, which happens when your list is large and when you load linked data from these objects \u2014 for example, Rails<\/a> associations.<\/p>\n
Avoid using functions that don\u2019t play well with iterators<\/h5>\n
When dealing with iterators, algorithmic complexity matters a lot. Each millisecond you can shave off counts. So when using iterators, you can avoid certain methods known to be slow. Instead, search for alternatives that can give you the same result without the performance penalty.<\/p>\n
The Date#parse\u00a0method is bad for performance, so avoid it. One solution is to specify the expected date format when parsing. So, suppose you\u2019re waiting for dates in the \u201cdd\/mm\/yyyy\u201d format. You could do it like this:<\/p>\n
Date.strptime(date, '%d\/%m\/%Y')<\/code><\/pre>\n
This will be considerably faster than what you\u2019d get by using the Date#parse method.<\/p>\n
Now let\u2019s consider type checks.<\/p>\n
The\u00a0Object#class, Object#is_a?, and Object#kind_of? methods might present bad performance when used in loops. The checks can take about 20ms, in large-ish loops. That might not sound too awful, but those times add up. Imagine a web application that performs such a comparison millions of times per request. If it\u2019s possible, it\u2019s advisable to move the calls to those functions away from iterators or even methods that called a lot.<\/p>\n
The Right Tool for the Job<\/h3>\n
I\u2019ll finish this post of tips on how to tune Ruby performance by advising you to\u2026 not write Ruby code all the time. Yeah, I know this might sound weird and defeatist, but hear me out for a moment. Ruby is an awesome language, and it\u2019s a general, multi-purpose language. This means that, yes, in theory, there\u2019s nothing stopping you from using Ruby to solve any kind of problem. But just because you can, does not mean you necessarily should.<\/p>\n
The essential point of this section is to say while Ruby is a great language, it doesn\u2019t have to be the sole tool in your tool belt. It\u2019s perfectly okay for you to mix and match and use other tools in areas where Ruby doesn\u2019t shine.<\/p>\n
With that out of the way, let\u2019s stop talking abstractions. Instead, we\u2019ll offer examples of realistic scenarios where maybe Ruby isn\u2019t the greatest choice, performance-wise. We\u2019ll also talk about better alternatives.<\/p>\n
C to the rescue<\/h4>\n
Since the main implementation of Ruby is written in C, rewriting a slow part of your Ruby code in C is always an alternative when you\u2019re facing performance issues. But there are better ways of leveraging the power of C\u2019s raw performance than writing fixes yourself. How would you do that? Simple: by using gems written by third parties in C.<\/p>\n
Some authors identify at least two types of those gems written in C. The first type would be gems that should replace slow parts of the Ruby language or even the Ruby on Rails framework. The other type refers to gems that implement specific tasks in C.<\/p>\n
Database to the rescue<\/h4>\n
It\u2019s not uncommon these days for developers\u2014especially web developers\u2014to ignore the most advanced capabilities of databases, using them essentially as glorified data storage tools. And that\u2019s unfortunate since databases often have sophisticated ways of dealing with complex computations using large amounts of data. This shouldn\u2019t be that surprising, but many developers miss out on those features.<\/p>\n
They probably opt for the comfort of relying on abstractions such as ORMs in order to not have to deal with SQL and other complex and inconvenient facets of databases. But by doing that, those developers are renouncing the data processing capabilities offered by those database systems. Understanding how to best leverages SQL databases and ORMs is a key component to successful Ruby performance tuning.<\/p>\n
Sometimes, when doing classification or ranking of data, you find yourself in a bad performance scenario, even after installing several gems and using them exactly as told. Maybe in this situation, the best solution would be to just perform the computation in SQL and be done with it.<\/p>\n
Sometimes developers will struggle with their ORMs or other tools when often-neglected database features such as materialized views would be a better solution.<\/p>\n
Tools at your disposal<\/h3>\n
\"\"<\/p>\n
Today\u2019s post featured basic tips you can apply to optimize the performance of your Ruby application. The list isn\u2019t exhaustive by any means; rather, treat it as a starting point to help you understand some of the most common Ruby performance problems.<\/p>\n
Once you get the right mindset, you will identify and troubleshoot not only the problems covered in this post but also problems in other areas.<\/p>\n
You don\u2019t have to face that journey all alone though. There are tools available that can help you troubleshoot performance issues in your Ruby and Ruby on Rails applications.<\/p>\n
One of these tools is Retrace<\/a>, a leading APM tool by Stackify. Some of Retrace\u2019s features include:<\/p>\n