One engine, many tools A few years ago, the new Ruby parser Prism was released. One of its primary goals was to unify the community since we had multiple implementations of Ruby parsers, each with their own bugs, differences in implementation and portability. By having a single parser, community investments in performance and correctness benefit every single tool built on top of it (including Ruby
movでEngineering Managerをしている南谷です。 RubyKaigi 2026に参加してきました。 ここ数日、参加した皆さんから様々な感想記事が上がってますね。 皆さんと同様、私も最高の3日間を過ごしまして、この高まった気持ちを放出して共感し合いたいところです。 いきなりですが宣伝ですというわけで、そんな想いの丈を解き放つ素敵なイベントを企画しました。 MEDLEYさんのオフィスでRubyKaigi事後勉強会をやります。 Omotesando.rb x Roppongi.rbの合同会をmovとMEDLEYさんで支援する形です。いつものLT会に近い感じになるとは思いますが、気軽に遊びに来てください。 皆さんで感想を語り合いましょうぞ。 宣伝終わり。 3日間色んなことがあったので話したいことは沢山あるのですが、この記事では、私が一番感銘を受けた、まつもとゆきひろさんのキーノー
はじめに こんにちは。アカツキゲームスの松下です。 弊社ではRailsを用いた大規模なゲームサーバを運用しており、お客様に良い体験を届けるべく、パフォーマンス改善が常に重要事項であり続けています。そのため、RubyにおけるJITコンパイラ・高速化技術であるYJITについても、登場時から注目していました。弊社でもこれまでに何度か導入を試みてきたものの、YJITを有効化すると負荷試験中に segmentation fault(SEGV)がごく稀かつランダムな箇所で発生するという現象に悩まされており、原因の特定すら難航する、歯痒い状態が続いている状況でした。 そのため、長らく本番導入を見送らざるを得ない状況が続いていましたが、一念発起し試行錯誤を重ねた結果、YJITとpitchforkのreforkingを本番環境に導入することに成功し、大きなパフォーマンス改善を得ることができました。 本記事で
What was the end-user or developer problem that led to this PR? Bundler awaits for the dependencies of a gem to be download and installed before it proceeds to downloading and installing the dependency itself. This creates a bottleneck at the end of the installation process and block a thread unnecessarily. Before After What is your fix for the problem, implemented in this PR? Details The installa
概要 CC BY-NC-SA 4.0 International Deedに基づいて翻訳・公開いたします。 英語記事: Faster bundler | Rails at Scale 原文公開日: 2026年03月09日 原著者: Edouard Chin、Eileen Uchitelle CC BY-NC-SA 4.0 Deed | 表示 - 非営利 - 継承 4.0 国際 | Creative Commons 日本語タイトルは内容に即したものにしました。 Shopifyでは開発環境の高速化が求められています。特にShopifyほど大規模なアプリケーションになると、依存関係のインストールにも時間がかかるものです。TypeScriptのbunやPythonのuvは、依存関係のインストール時間を劇的に改善しましたが、同じことがBundlerとRubyコミュニティでも実現可能だとしたら嬉しいで
はじめに crowdworks.jp のジャンヌチームで主にバックエンドの技術的負債の解消に取り組んでいる @kotarou1192 です。 crowdworks.jp を支える Rails アプリケーションで YJIT を有効化しました。 本記事では、有効化の背景と、1週間の観察で得られたパフォーマンスの変化を報告します。 YJIT とは YJIT は Ruby 3.1 で実験的に導入された JIT コンパイラです。 Ruby 3.2 で本番利用可能な品質となり、Ruby 3.3 ではさらなるパフォーマンス改善が加えられています。 Lazy Basic Block Versioning (LBBV) という手法により、実行時にコードを Basic Block 単位で遅延的にネイティブコードへコンパイルすることで、インタプリタ実行と比較して高速化を実現します。 Ruby 3.3 における
こんにちは、SmartHR プロダクトエンジニアのB6です。 「基本機能」と呼ばれるSmartHR最大のRailsアプリケーションでは、アプリケーションサーバにPumaを使用しています。 RailsでPumaデフォルトスレッド数が変更されたのをきっかけに、私たちもスレッド数の設定を見直してみたいと思うようになりました。 本記事では、調整の際に行ったこととその結果について共有いたします。 背景 2024年、RailsでPumaのデフォルトスレッド数を減らすための議論が展開されました(Issue #50450)。議論の結果、I/O比率を25~50%とする一般的なRailsアプリケーションでは、スレッド数3が適切ではないかという結論に至りました。 要点をざっくりまとめると以下のようになります。 CRubyでは、GVLが存在するため、同時に1つのスレッドしかRubyコードを実行できない Pumaの
5年振りのメジャーバージョンアップとなるRuby 4.0正式リリース、クラスの定義などを隔離するRuby Box、新JITコンパイラ「ZJIT」搭載など Ruby開発チームは2025年12月25日、Ruby 4.0の正式リリースを発表しました。 Rubyは毎年12月25日に新バージョンをリリースすることが恒例となっており、2024年も予定通りに新バージョンが登場しました。しかも今回は2020年にRuby 3.0が登場して以来5年振りのメジャーバージョンアップとなりました。 Rubyはまつもとゆきひろ氏により1993年に開発が始められたプログラミング言語です。シンプルで生産性の高いプログラムを書くことができることなどを特長とし、Ruby on Rails(Rails)と呼ばれるWebアプリケーションを容易に構築できるフレームワークを備えていることで人気のプログラミング言語です。 Ruby 4
はじめに 「Railsって遅いよね」——この言葉を聞いたことがあるでしょうか。確かにRailsは機能が豊富な分、雑に作ると簡単に遅くなります。しかし、その遅さの原因はフレームワークそのものよりも、アプリサーバ設定、DBクエリ、キャッシュ設計、運用スタックの複雑さに起因することが多いのです。 この記事では、「何から手を付ければ速くなるのか」が見えにくい状況を解消するために、実践的な手順とテンプレートをまとめます。 改善の進め方 パフォーマンス改善は以下の順番で進めると迷いにくくなります。 なぜこの順番か? 計測: ボトルネックを特定しないまま最適化しても効果が薄い Puma: アプリサーバの設定ミスは全リクエストに影響する N+1: 最も一般的かつ効果の出やすい改善ポイント DB: インデックス追加は低リスクで効果大 キャッシュ: 計算結果の再利用で負荷を大幅削減 非同期処理: ユーザー体感
概要 CC BY-NC-SA 4.0 Deedに基づいて翻訳・公開いたします。 英語記事: Interprocedural Sparse Conditional Type Propagation | Rails at Scale 原文公開日: 2025/02/24 原著者: Max Bernstein、Maxime Chevalier-Boisvert CC BY-NC-SA 4.0 Deed | 表示 - 非営利 - 継承 4.0 国際 | Creative Commons 日本語タイトルは内容に即したものにしました。 参考: 疎な条件分岐を考慮した定数伝播(Sparse conditional constant propagation) - Wikipedia 11時をお知らせします。皆さんの大事な変数がどこを指しているかちゃんと把握していますか?1 def shout(obj) ob
Following Maxime’s presentation at RubyKaigi 2025, the Ruby developers meeting, and Matz-san’s approval, ZJIT has been merged into Ruby. Hurray! In this post, we will give a high-level overview of the project, which is very early in development. ZJIT is a new just-in-time (JIT) Ruby compiler built into the reference Ruby implementation, YARV, by the same compiler group that brought you YJIT. We (M
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: So You Want To Remove The GVL? | byroot’s blog 原文公開日: 2025/01/29 原著者: byroot -- Railsコアコミッター、Rubyコミッターであり、ShopifyのRuby/Railsインフラチームのシニアスタッフエンジニアです 日本語タイトルは内容に即したものにしました。 GVLは「グローバルVMロック」の略ですが、「ジャイアントVMロック」とされることもあります。 参考: Rubyの(グローバル)VMロックをトレースする(翻訳) 参考: スレッド (Ruby 3.4 リファレンスマニュアル) 私がやりたいのは、Pitchforkに関する記事を書いて、これがどんな理由でできたのか、なぜ現在のような形になったのか、そして今後どうなるのかについて説明することです。しかし
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
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
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
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
2024年5月15〜17の3日間、沖縄県那覇市で開催されたRubyKaigi2024に参加してきました! 今年も楽しかったですね・・・! だいぶ間が空いてしまいましたが、聴講したトークや思ったことなど書いてみました。 トーク感想 Day1 The grand strategy of Ruby Parser by Yuichiro Kaneko 発表資料 Ruby3.3で導入されたパーサージェネレータであるLramaについて、どんなものなのか、それがなぜ選ばれたのか、そして現在のRubyのパーサ周りの開発がどのような状況かといった内容でした。 まずここでいうパーサとは、Rubyのコードを解釈してASTとして出力するためのものです。 出力されたASTは、主にLSPのような開発支援の外部ツール等で使われます。 Ruby3.3では、それまでのBisonに代わってLramaというRubyで書かれた新
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く