Measure the runtime of your Ruby code in production, easily.

Track specific methods in your application with Timeasure's elegant class macros
Report the collected timing data to an analytics framework of your choice (NewRelic, Google Analytics, Keen...)
Make informed decisions and aim at the most beneficial runtime optimization tasks


Timeasure is a Ruby gem created and maintained by Eliav Lavi & Riskified. Timeasure allows measuring the runtime of methods without having to alter the code of the methods themselves. Timeasure is intended to be used in production environments in order to achieve a real picture of methods' runtime. It is indeed used in production in Riskified, however please note that it is still in its pre-release period, so please take extra care and check it locally before deploying to production.

To achieve an easy and intuitive interface, Timeasure offers elegant class macros, similar in syntax to Ruby's attr_accessor or Rails' validates_uniquness_of.

Timeasure handles the runtime measurement of declared tracked methods and aggregates them on the method level. It is recommended to report this data to an analytics framework that allows insights gathering the end of transaction. Timeasure was designed with NewRelic Insights as the "inspiration on the other end", but it is generic enough to fit to other analytics frameworks.

Below is a possible usage of Timeasure within a given class. Notice how the declaration of which methods to track only changes the code at the top of the class while the tracked methods remain intact:

class Foo

def self.baz

# some class-level works goes here...


def bar

data = something_heavy

arranged_data = something_lighter(data)




def something_heavy

# some querying goes here...


def something_lighter(data)

# some data wrangling goes here...


def something_optional

# some code that gets called sometimes and sometimes not goes here...


def compute(arranged_data)

# some machine learning stuff goes here...




We strive to build fast and efficient web applications and web services. The need for speed might derive from contractual obligations, ongoing product improvement efforts, or the very desire to write better, faster code. Measuring the production runtime of different methods in different classes and analyzing this data is crucial in the process of optimizing the agility of any application's backend parts.

Timeasure was created in order to make the gathering of this data easy and organized. Instead of modifying the methods you wish to measure, handling the results of the measurements and along the way indenting many lines of code, Timeasure offers simple class macros that help with separating the concern of methods measurement from the methods themselves. In addition, Timeasure is equipped with a handy Profiling Manager that keeps track of reported methods in an aggregated way. This part is configurable, should you want to use another tool to collect measurement data.


To demonstrate Timeasure's abilities, this page was actually built as part of a Rails mock-app.

The app includes some made-up code that serves as an imaginary job. It is measured by Timeasure and reports the collected information back to this view, right at the end of the transaction.

See the source code of the demo job here.

Class Name Method Name Call Count Runtime Sum (ms)

To gain useful knowledge from this information, it is recommended to send it to some analytics framework. For example, on NewRelic Insights, it might look like this: New relic graph



Timeasure is consisted of the core method measuring aspect and of a profiler, which gathers the measured methods runtime data. After adding Timeasure to your projects Gemfile, you may track methods easily as demonstrated in the What is Timeasure section.


By default, any tracked method will report its runtime to Timeasure's profiler - Timeasure::Profiling::Manager. What this means to you is that you are responsible of managing the clean-up and the reporting of the aggregated data. It is recommended to prepare the profiler at the beginning of a transaction in which tracked methods exist with Timeasure::Profiling::Manager.prepare and to re-prepare it again at the end of the transaction to ensure a "clean slate" - after you have handled the aggregated data in some way.


In order to get hold of the reported methods, use Timeasure::Profiling::Manager.export. This will return an array of ReportedMethod objects. See here for further information.

Have a look at the README for further details