# Call to Action: Long running Ruby benchmark

DevFeed: [Call to Action: Long running Ruby benchmark](<https://devfeed.tech/articles/call-to-action-long-running-ruby-benchmark-41333.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2013/12/11/call-to-action-long-running-ruby-benchmark>)

Author: Sam Saffron

Published: 2013-12-11T04:21:43Z

Content type: opinion

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [Ruby](<https://devfeed.tech/topics/ruby.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [Development](<https://devfeed.tech/topics/development.md>), [Hardware](<https://devfeed.tech/topics/hardware.md>)

Tags: [benchmark](<https://devfeed.tech/tags/benchmark.md>), [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [performance](<https://devfeed.tech/tags/performance.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>)

## AI overview

The article calls for a long-running Ruby and Rails benchmarking project to track performance changes over time, identify regressions early, and attribute improvements or slowdowns to specific changes. It proposes testing multiple Ruby implementations, real-world applications, microbenchmarks, and dedicated hardware across a broad set of metrics.

## Source excerpt

I would love a long running Ruby and Rails set of benchmarks. I talked about this at GoGaRuCo and would like to follow up. For a very long time Python has had the pypy speed center: 493197bf05a35c45.png1313x536 80 KB Recently, golang has added its own: http://goperfd.appspot.com/perf ee97ffd44621be66.png1767x702 112 KB Why is this so important? Writing fast software requires data. We need to know right away when our framework or platform is getting slower or faster. This information can be fed directly to the team informing them of big wins and losses. Often small changes can lead to unexpected gains or losses. Finding out about regressions months into the development cycle can often incur a massive cost, fixing bugs early on is cheap. Usually the longer we wait the more expensive it is to fix. 8e0e8bee19691403.png632x293 131 KB Source: NASA Imagine if for every Rails major release the team could announce not only that it is N% faster in certain areas but also attribute the improvements to particular commits. Imagine if we could have a wide picture about the performance gains and losses of new Ruby versions, given full context to the reason why something slowed down or sped up. What we have today? We have a fair amount The Discourse benchmarks see: http://meta.discourse.org/t/benchmarking-discourse-locally/9070 The benchmarks bundled with Ruby see: https://github.com/ruby/ruby/tree/trunk/benchmark Other benchmarks see: miguelcamba.com A server provisioned by Ninefold to run the long running benchmarks and host a site A lot of Ruby implementations to test (MRI, JRuby, Rubinius) A place to start contributing code: GitHub - SamSaffron/ruby-bench-play Discourse is very close to working on Rails master now, and works fine on Ruby head. The Discourse benchmark can be used to benchmark a "real world" app, it integrates the entire system. The other small microbenchmarks can be used to bench specific features and areas. The importance of stable dedicated hardware The server