In the first post in the Ruby Garbage Collection Deep Dive series, we went through a few definitions to give us a picture of how Ruby stores values in memory. If you haven’t read it yet, read it first! We’ll build on those definitions in this post. Particularly, we’ll talk more about the Ruby Heap, Pages, Slots and RVALUES.
Okay, now that we have those baseline definitions out of the way, this post is going to explain the algorithm Ruby’s garbage collector uses to determine which objects it can collect: the Tri-Color Mark and Sweep algorithm. There are two phases to this algorithm. You guessed it: marking and sweeping. In the marking phase, the garbage collector marks all slots which contain accessible RVALUES. In the sweeping phase, the garbage collector clears the RVALUES out of all slots which are not marked. Let’s dig in!
With the Ruby 3.0 release, there’s been a lot of chatter about concurrency, parallelism, and async IO.
For my own reflection, I wanted to write down what that means for performance and capacity/costs of apps, and what would be the impact on the Ruby ecosystem.
I will assume that the audience already knows the difference between threads vs processes model in UNIX and the Little’s law.
Following up on my last blog post, I am going to look at how Ruby is used to get a bit of an impression of whether there are major differences between Ruby and Smalltalk in their usage.
Again, I am going to look into the structural aspects of code bases. This means, looking at classes, methods, modules, and files.
When Basecamp launched in February of 2004, we ran on a single shared Linux server at Tilted. I don’t fully remember the CPU spec, but I do remember that we had the same 256MB of RAM available. And I believe the monthly cost for this princely server was around $349. It was not only fast enough to run Rails and Basecamp, but good enough to do so on its own for more than a year while we built a business that could pay the salaries of four.
So forgive me if the zombie theme of “Ruby is so damn slow” isn’t striking a recognizable tune with me. Now, I don’t for a minute doubt that Ruby may well be too slow for some people doing some things. But given the fact that Ruby was plenty fast for me in 2003 on a bootstrapped budget with the performance of the day, I think perhaps that tune is out of key for many others too.
We built an application used by millions of people that has made tens of millions of dollars in real money and continues to grow and prosper. No, it’s certainly not Internet Scale™. And it certainly doesn’t prove that Ruby is fast enough to be economical when you get there, but it does lodge an anecdote that it’s probably more than fast enough for most people doing most things.
With Ruby 3.0 just around the corner, let’s take a look at one of the highlights of the upcoming release: Ruby Type Signatures. Yes, types are coming to our favorite dynamic language! Let’s see how to take advantage of them by adding types to a real-world open source project and looking at the finer points of the process.
We are pleased to announce the release of Ruby . From 2015 we developed hard toward Ruby 3, whose goal is performance, concurrency, and Typing. Especially about performance, Matz stated “Ruby3 will be 3 times faster than Ruby2” a.k.a. Ruby 3x3.
Ruby 3x3 announced that Ruby 3.0 would be three times as fast as Ruby 2.0. It was an audacious goal, especially for a language released in 1995.
Ruby 3 is due to be released in less than a month. They’re hard at work on some of the features, but non-JIT performance is pretty close to release speed. If they pull another 5%-10% speed increase at the last minute (which happened for Ruby 2.5!) it’ll be surprising. The current performance is basically the “real” Ruby 3 performance.
So… Did it happen? Is Ruby 3 really three times the speed?