Comparison with Other Profilers¶

Ruby has several excellent profiling tools, each with different strengths. This page compares ruby-prof with three popular alternatives to help you choose the right tool for your needs.

Tracing vs Sampling¶

The most important distinction between profilers is tracing vs sampling:

• Tracing profilers (ruby-prof) instrument every method call and return. This provides exact call counts and complete call graphs, but adds overhead to every method invocation.
• Sampling profilers (stackprof, rbspy, vernier) periodically capture stack snapshots. This has much lower overhead but may miss short-lived method calls.

Overview¶

The table below compares ruby-prof with stackprof, rbspy, and vernier — the three most popular sampling profilers for Ruby.

Measurement Capabilities¶

Report Formats¶

When to Use Each¶

ruby-prof¶

ruby-prof is the longest-standing Ruby profiler, with its first release in 2005. It has been continuously maintained for nearly two decades, evolving alongside Ruby itself from 1.8 through 4.0. Over that time it has supported every major Ruby version and platform, including Windows — a rarity among Ruby C extensions.

Being a tracing profiler, ruby-prof provides exact information about your program. It tracks every thread, every fiber and every method call. It shines with its support for multiple measurements modes and excellent reporting capabilities.

ruby-prof can be used from the command line with no code changes, or via an API for more control.

The biggest downsides of ruby-prof are:

• It adds significant overhead for running programs, so is not suitable for production use
• It must start a Ruby program, it cannot attach to an already running program

stackprof¶

stackprof is a low-overhead, sampling profiler that is good for development. It adds minimal overhead while still providing useful flame graphs and per-line hit counts. A good choice when you want something lightweight and well-established.

The biggest downsides of stackprof are:

• Single-thread only
• Linux only for time-based modes

rbspy¶

rbspy is a sampling profiler best for profiling in production or when you cannot modify the application code. As an external process, it attaches to a running Ruby process by PID with zero code changes. It is particularly useful for profiling third-party Ruby applications (Chef, Puppet, etc.), investigating slow test runs, or quick profiling of scripts via rbspy record ruby my-script.rb. Supports the widest range of Ruby versions.

The biggest downsides of rbspy are:

• No allocation profiling
• No call graph or caller/callee data

vernier¶

vernier is a sampling profiler best for diagnosing concurrency issues and understanding GVL contention. It is the only Ruby profiler that reports GVL state, GC pauses and idle time. Its Firefox Profiler integration provides rich interactive visualizations with per-thread timelines.

The biggest downsides of vernier are:

• Requires Ruby 3.2.1+
• No Windows support

rack-mini-profiler¶

rack-mini-profiler is a "batteries-included" profiling tool for Rails and Rack applications. It uses stackprof under the hood for CPU profiling while also supporting memory profiling. It is a good choice if you want an integrated profiling solution that works directly in the browser during development.

Memory Profiling¶

memory_profiler is another profiler, but it focuses exclusively on memory usage. It uses Ruby's ObjectSpace API to track every object allocation during a block of code, recording the source file, line number, object type, and size via ObjectSpace.memsize_of. By snapshotting the GC generation before and after, it distinguishes between allocated objects (created during the block) and retained objects (still alive after GC). This makes it useful for finding memory leaks and identifying allocation-heavy code. It's pure Ruby with no C extension, so it works across Ruby versions and platforms.

ruby-prof can track allocation counts via its RubyProf::ALLOCATIONS mode, but memory_profiler gives deeper insight into memory specifically — object sizes, retained vs allocated, and per-gem breakdowns.