--- title: Ruby and Rails Performance Roundup: The Backlog Edition description: A roundup of forty recent Ruby and Rails performance improvements pulled from the author's backlog, each with benchmark numbers from the original PRs.... canonical: https://daily.dev/posts/ruby-and-rails-performance-roundup-the-backlog-edition-cmpjsw8ud twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Ruby and Rails Performance Roundup: The Backlog Edition | daily.dev og:description: A roundup of forty recent Ruby and Rails performance improvements pulled from the author's backlog, each with benchmark numbers from the original PRs.... og:url: https://daily.dev/posts/ruby-and-rails-performance-roundup-the-backlog-edition-cmpjsw8ud og:image: https://api.daily.dev/og/posts/CmpJSw8Ud.png og:image:alt: Ruby and Rails Performance Roundup: The Backlog Edition og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Ruby and Rails Performance Roundup: The Backlog Edition **[RUBYLAND](https://daily.dev/sources/rubyla)** · 9 min read · 0 upvotes · 0 comments ## Summary A roundup of forty recent Ruby and Rails performance improvements pulled from the author's backlog, each with benchmark numbers from the original PRs. Highlights include Koichi Sasada's per-Ractor GC (cutting 16-Ractor GC overhead from 10.17x to 3.32x single-Ractor wall time), several ZJIT/YJIT specialization fixes from Takashi Kokubun, a 378x speedup fixing quadratic decoding in JSON::ResumableParser, faster Monitor and String#dup via GC fast-path inlining, Rails fixes like batched table creation (2 minutes to 25 seconds on a 1000+ table schema), Range#cover? replacing slow iteration in this_year?/this_month?, deferred Action Cable dispatch fixes, and Ruby boot-time and Windows I/O improvements. Each entry links to the original pull request and notes the contributor. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why did JSON::ResumableParser get so much faster at parsing very large numbers in chunks? It used to fully decode an incomplete number into a bignum on every chunk it received, then throw that partial result away until the number was complete, making the cost quadratic. Deferring the decode until the number is finished makes the cost linear: a 128,000-digit number fed in 128-byte chunks dropped from 3.07 seconds to 8.13 milliseconds, roughly a 378x improvement, fixed by Masataka Kuwabara. _Track granular Ruby JSON parser fixes like this one on daily.dev as you tune hot paths._ ### How does per-Ractor garbage collection improve Ruby's scaling with many Ractors? Each Ractor gets its own object space so local garbage collection runs without stopping the whole world, and a global GC only triggers when shareable objects or dead Ractors need reclaiming. On a JSON-parsing benchmark, going from 1 to 16 Ractors previously cost 10.17x the single-Ractor wall time; with per-Ractor GC it drops to 3.32x, close to forked-process parity at 3.28x, implemented by Koichi Sasada. _Developers evaluating Ractor concurrency can follow GC internals changes like this on daily.dev._ ### Why is Rails' this_year? method so much slower than it needs to be? this_year?, this_month?, and this_week? walked their entire date range using Range#include? and its #succ iteration, meaning this_year? stepped through roughly 365 individual dates on every call. Replacing that with Range#cover?, which just compares endpoints, yields a 10-100x speedup depending on the period, fixed in a Rails pull request by Kenta Ishizaki. _Rails developers hunting hidden perf traps like this can follow fixes like it on daily.dev._ ## Similar posts on daily.dev - [Small PRs, big speedups: The Ruby performance work you almost missed](https://daily.dev/posts/small-prs-big-speedups-the-ruby-performance-work-you-almost-missed-y3nfbjmzf) · RUBYLAND · 0 upvotes · 0 comments - [Issue \#806: A Rails blog app in a ~500KB binary — Ruby Weekly](https://daily.dev/posts/issue-806-a-rails-blog-app-in-a-500kb-binary-ruby-weekly-gys5pxamy) · Ruby Weekly · 0 upvotes · 0 comments - [i coercion, custom to](https://daily.dev/posts/i-coercion-custom-to-w1nutb2rf) · This Week in Rails · 0 upvotes · 0 comments - [Ruby and Rails investigations](https://daily.dev/posts/ruby-and-rails-investigations-4kiin1fjd) · Ruby Flow · 0 upvotes · 0 comments --- Tags: [#performance](https://daily.dev/tags/performance), [#ruby](https://daily.dev/tags/ruby), [#rails](https://daily.dev/tags/rails) [View this post on daily.dev](https://daily.dev/posts/ruby-and-rails-performance-roundup-the-backlog-edition-cmpjsw8ud) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Ruby and Rails Performance Roundup: The Backlog Edition","url":"https://daily.dev/posts/ruby-and-rails-performance-roundup-the-backlog-edition-cmpjsw8ud","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/ruby-and-rails-performance-roundup-the-backlog-edition-cmpjsw8ud"},"datePublished":"2026-08-12T15:49:19.041Z","dateModified":"2026-08-12T15:49:51.605Z","description":"A roundup of forty recent Ruby and Rails performance improvements pulled from the author's backlog, each with benchmark numbers from the original PRs....","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4bbed533a6a39ef165459373c82cf3c8?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4bbed533a6a39ef165459373c82cf3c8?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"RUBYLAND","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"RUBYLAND","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/rubyla","url":"https://daily.dev/sources/rubyla"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/ruby-and-rails-performance-roundup-the-backlog-edition-cmpjsw8ud","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"performance,ruby,rails","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"RUBYLAND","item":"https://daily.dev/sources/rubyla"},{"@type":"ListItem","position":3,"name":"Ruby and Rails Performance Roundup: The Backlog Edition"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/ruby-and-rails-performance-roundup-the-backlog-edition-cmpjsw8ud#faq","mainEntity":[{"@type":"Question","name":"Why did JSON::ResumableParser get so much faster at parsing very large numbers in chunks?","acceptedAnswer":{"@type":"Answer","text":"It used to fully decode an incomplete number into a bignum on every chunk it received, then throw that partial result away until the number was complete, making the cost quadratic. Deferring the decode until the number is finished makes the cost linear: a 128,000-digit number fed in 128-byte chunks dropped from 3.07 seconds to 8.13 milliseconds, roughly a 378x improvement, fixed by Masataka Kuwabara. Track granular Ruby JSON parser fixes like this one on daily.dev as you tune hot paths."}},{"@type":"Question","name":"How does per-Ractor garbage collection improve Ruby's scaling with many Ractors?","acceptedAnswer":{"@type":"Answer","text":"Each Ractor gets its own object space so local garbage collection runs without stopping the whole world, and a global GC only triggers when shareable objects or dead Ractors need reclaiming. On a JSON-parsing benchmark, going from 1 to 16 Ractors previously cost 10.17x the single-Ractor wall time; with per-Ractor GC it drops to 3.32x, close to forked-process parity at 3.28x, implemented by Koichi Sasada. Developers evaluating Ractor concurrency can follow GC internals changes like this on daily.dev."}},{"@type":"Question","name":"Why is Rails' this_year? method so much slower than it needs to be?","acceptedAnswer":{"@type":"Answer","text":"this_year?, this_month?, and this_week? walked their entire date range using Range#include? and its #succ iteration, meaning this_year? stepped through roughly 365 individual dates on every call. Replacing that with Range#cover?, which just compares endpoints, yields a 10-100x speedup depending on the period, fixed in a Rails pull request by Kenta Ishizaki. Rails developers hunting hidden perf traps like this can follow fixes like it on daily.dev."}}]} ```