fast-ruby: a benchmarked catalogue of Ruby idioms, not a gem you install

What fast-ruby actually is, and who it is for

fast-ruby is a catalogue, not a library. The README opens by crediting Erik Michaels-Ober's talk 'Writing Fast Ruby' and says the author documented those idioms so more people would know them. There is no runtime dependency to add and no API to call. What the repository ships is a README of paired idioms and a code directory holding one runnable script per pair.

The audience is narrow and specific. You are writing Ruby, something is slow, and you have narrowed the problem to a construct rather than an algorithm: a getter, a string method, a hash lookup, a block. At that point a table of measured comparisons is more useful than intuition. The README is blunt about the boundary: 'This does not mean you can always blindly replace one with another. It depends on the context (e.g. gsub versus tr).' That sentence is the whole contract. The project gives you data and tells you not to apply it mechanically.

It is not a Rails performance guide. The idioms are language level: attr_accessor, begin/rescue, define_method, String#constantize, Kernel#raise, and similar. If your bottleneck is a database query or an N+1 association load, nothing here addresses it.

How the benchmark pairs are structured

Every idiom in the README follows the same shape. Two implementations are defined, one labelled fast and one labelled slow, and benchmark-ips reports both with a comparison line. The README's template shows the pattern directly:

require "benchmark/ips"

def fast
end

def slow
end

Benchmark.ips do |x|
  x.report("fast code description") { fast }
  x.report("slow code description") { slow }
  x.compare!
end

The output is a warmup phase, a calculating phase with iterations per second and a standard deviation, and then a ratio. For the attr_accessor pair the README shows 12,517,008.0 i/s against 10,999,275.5 i/s, printed as '1.14x slower'. The raise versus E2MM#Raise pair shows 29.12x. That spread matters: some of these pairs are noise-adjacent and others are not, and the comparison line tells you which is which. The define_method versus module_eval pair is explicitly labelled 'same-ish: difference falls within error', which is the project being honest about a result it could have presented as a win.

Each README entry links to its script under code/, organised by category: General, Array, Date, Enumerable, Hash, Proc & Block, String, Time, Range. The README also states that all listed results were produced with Ruby 4.0.0 on macOS 15.6.1, on a MacBook Pro with an Apple M4 Pro and 48 GB RAM, and adds 'Your results may vary, but you get the idea.' A GitHub Actions workflow runs the same benchmarks against different Ruby implementations, and the README points readers there for those results.

Running a single idiom script on your own machine

There is nothing to install. The repository has a Gemfile and a Rakefile, but the README's own example invokes a script directly with ruby, which is the shortest path to a real number. Clone the repository, then run one script and read the comparison block at the bottom of the output:

ruby -v code/general/attr-accessor-vs-getter-and-setter.rb

The script requires benchmark/ips, so that gem has to be available to the interpreter you use. The README names benchmark-ips 2.0+ as the measurement tool. Expect a warmup section, a calculating section with i/s figures, and a final comparison line naming a winner and a ratio. If the ratio is close to 1x, treat the pair as equivalent on your hardware regardless of what the README's machine reported.

For the other half of the workflow, the README points at a separate project: 'Checkout the fasterer project - it's a static analysis that checks speed idioms written in this repo.' That is the path from reading to enforcement. fasterer is a distinct repository, not a directory inside fast-ruby, and the README does not document its configuration or how to wire it into a build.

The numbers are machine-specific and the README says so

The first real limitation is stated in the README rather than discovered by a reader. All results come from one Ruby version on one operating system on one machine. Ruby's internals change between releases, and a method that was faster in one version can lose its advantage or reverse after an optimisation lands in the interpreter. A ratio measured on an M4 Pro under macOS says nothing about a shared CI runner on Linux, and nothing about JRuby or TruffleRuby, whose execution models differ enough that instruction-level comparisons may not transfer at all.

The second limitation is the one the README repeats: context decides. The gsub versus tr example is the clearest case, because the two methods are not interchangeable in behaviour, only in the narrow case where you are replacing single characters. Applying the faster form there changes what the code does. The same caution applies to begin/rescue versus respond_to?: the measured gap is large, but they express different intent, and swapping one for the other to gain speed can hide a real error path.

A third gap is structural. The repository has no releases and the README documents no versioning scheme, so there is no changelog to consult when a Ruby upgrade invalidates a result. You re-run the scripts.

fasterer, and how it differs from reading the README

The natural alternative is fasterer, which the README itself recommends. The difference is in the mode of use. fast-ruby is a catalogue you read and run by hand: you pick a pair, execute the script, and interpret the output. fasterer is static analysis that inspects your source and flags idioms matching the patterns collected here. One answers 'is this construct slower, and by how much'; the other answers 'where in this codebase does the pattern appear'.

That difference has consequences. A static checker can point at a line without knowing whether that line is on a hot path, which is exactly the mistake the README warns against. Reading the benchmarks yourself costs more time but forces the question of whether the code in question runs often enough to matter. Neither tool profiles your application. If you do not know where the time goes, both are premature: fast-ruby gives you ratios between two constructs, not a profile of your program.

Maintenance, licensing and what to verify

The repository is not archived, and the last push was on 2026-06-28. That is recent enough that the benchmark set reflects a current Ruby, and the README's Ruby 4.0.0 results are consistent with that timing. There are no tagged releases, so there is no upgrade path to plan: you pull the default branch and re-run the scripts. The cost of staying current is the cost of re-running benchmarks after a Ruby upgrade, which is a few commands rather than a migration.

The licence is the open question. The repository root contains a CC-BY-SA.png file, which suggests a Creative Commons Attribution-ShareAlike licence, and the README's own text is prose and benchmark output rather than code. But no licence identifier is stated in the README, and the code directory contains Ruby scripts whose terms are not spelled out there. If you intend to copy the example scripts into your own project rather than read them, confirm the licence terms from the repository itself first. This is a factual gap, not a legal opinion, and it is the one thing to check before reuse.

Editorial conclusion

Adopt fast-ruby as a reading list if you maintain Ruby that runs hot, and as a lint target if you want fasterer to flag these patterns in CI. Do not adopt it if you are looking for a gem to add to your Gemfile, a Rails-specific tuning guide, or a reason to rewrite code you have not measured. Before trusting any pair, run the script in code/ on your own Ruby version and hardware, because the README's numbers come from one machine and the project itself warns that the faster form is not always the correct form.

Frequently asked questions

Official sources

1. fastruby/fast-ruby on GitHub
2. Issues
3. Project website
4. README