Optimizing Ruby Path Methods
Back in November last year, I started a new job at Intercom, and one of the first projects I got to work on was improving the Intercom monolith CI with some of my new colleagues. Interestingly, I never got around to talking about CI on this blog, even though I consider it to be one of my main areas of expertise. That topic is way beyond the subject I’d like to talk about here, but just to give a b
Frozen String Literals: Past, Present, Future?
If you are a Rubyist, you’ve likely been writing # frozen_string_literal: true at the top of most of your Ruby source code files, or at the very least, that you’ve seen it in some other projects. Based on informal discussions at conferences and online, it seems that what this magic comment really is about is not always well understood, so I figured it would be worth talking about why it’s there, w
Dear Rubyists: Shopify Isn’t Your Enemy
I’ve been meaning to write a post about my perspective on Open Source and corporate entities. I already got the rough outline of it; however, I’m suffering from writer’s block, but more importantly, the whole post is a praise of how Shopify engages with Open Source communities. Hence, given the current climate, I don’t think I could publish it without addressing the elephant in the room first anyw
What’s wrong with the JSON gem API?
As I mentioned at the start of my Optimizing Ruby’s JSON series of posts, performance isn’t why I candidated to be the new gem’s maintainer. The actual reason is that the gem has many APIs that I think aren’t very good, and some that are outright dangerous. As a gem user, it’s easy to be annoyed at deprecations and breaking changes. It’s noisy and creates extra work, so I entirely understand that
Unlocking Ractors: class instance variables
In a previous post about ractors, I explained why I think it’s really unlikely you’d ever be able to run an entire application inside a ractor, but that they could still be situationally very useful to move CPU-bound work out of the main thread, and to unlock some parallel algorithm. But as I mentioned, this is unfortunately not yet viable because there are many known implementation bugs that can
What’s The Deal With Ractors?
I want to write a post about Pitchfork, explaining where it comes from, why it is like it is, and how I see its future. But before I can get to that, I think I need to share my mental model on a few things, in this case, Ractors. When Ractors were announced 4 or 5 years ago, many people expected we’d quickly see a Ractor-based web server, some sort of Puma but with Ractors instead of threads. Yet
So You Want To Remove The GVL?
I want to write a post about Pitchfork, explaining where it comes from, why it is like it is, and how I see its future. But before I can get to that, I think I need to share my mental model on a few things, in this case, Ruby’s GVL. For quite a long time, it has been said that Rails applications are mostly IO-bound, hence Ruby’s GVL isn’t that big of a deal and that has influenced the design of so
Why Does Everyone Hate fork(2)?
I want to write a post about Pitchfork, explaining where it comes from, why it is like it is, and how I see its future. But before I can get to that, I think I need to explain a few things, namely why in many circles fork is seen as a relic of the past, if not outright the devil’s creation. And yet, it’s ubiquitous in the Ruby ecosystem. Note that if you have some system programming experience, yo
Optimizing Ruby’s JSON, Part 7
In the previous post, we started covering some parser optimizations. There’s just a handful more to cover until we reached what’s the state of the currently released version of ruby/json. Batch APIs But as always, let’s start with a flame graph of twitter.json, to see what was left to optimize: Full profile. Something that was bothering me in that profile, was the whopping 26.6% of time spent in r
Optimizing Ruby’s JSON, Part 6
After wrapping up about the encoder optimizations in the previous post, we can now start talking about the parser side. It certainly won’t be as long, because the parser didn’t need as much work, but also because some optimizations, particularly around setup costs were the same as the one applied to the encoder, so I will simply reference them quickly. Efficient Hash Operations When I took over th
Optimizing Ruby’s JSON, Part 5
In the previous post, we showed how we eliminated two malloc/free pairs of calls when generating small JSON documents, and how that put us ahead of Oj when reusing the JSON::State object. But that API isn’t the one people use, so if we wanted to come out ahead in the micro-benchmarks users might perform themselves, we had to find a way to get rid of that JSON::State allocation too, or to somehow m
Optimizing Ruby’s JSON, Part 4
In the previous post, we established that as long as ruby/json wasn’t competitive on micro-benchmarks, public perception wouldn’t change. Since what made ruby/json appear so bad on micro-benchmarks was its setup cost, we had to find ways to reduce it further. Spot the Seven Differences So I decided to file this performance discrepancy as a bug, and investigate it as such and started profiling Step
Optimizing Ruby’s JSON, Part 3
In the previous post, I covered how I reimplemented JSON::Generator::State#configure in Ruby and some other changes. Unfortunately, it didn’t go as well as I initially thought. Mistakes Were Made The default gems that ship with Ruby are automatically copied inside ruby/ruby’s repo. In short, there’s a bot aptly named matzbot, that replicates all the commits from the various ruby/* gems, inside rub
Optimizing Ruby’s JSON, Part 2
In the previous post, I covered my motivations for improving ruby/json’s performance, and detailed the first 4 notable optimizations applied to speed up JSON generation. If I was to cover every single optimization applied, at this rate I’d end up with a dozen parts, so I’ll try to only focus on the one that made a significant difference or used an interesting pattern. Reducing Setup Cost - Argumen
Optimizing Ruby’s JSON, Part 1
I was recently made maintainer of the json gem, and aside from fixing some old bugs, I focused quite a bit on its performance, so that it is now the fastest JSON parser and generator for Ruby on most benchmarks. Contrary to what one might think, there wasn’t any black magic or deep knowledge involved. Most of the performance patches I applied were fairly simple optimizations driven by profiling. A
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unlocking Ractors: generic instance variables