Charlie Park

Benchmarking and in Ruby

There are often times when I can handle a programming issue in one of two (or more) ways. Dealing with Time / Date objects is one of those situations.

For example, if you want to know what day today is, you can either fetch or

In my head, Date is a much simpler concept than Time. After all, Time deals with things like milliseconds and Epochs and things like that, where Date … well, I woke up this morning, and it was today’s date. And when I get up tomorrow, it’ll be tomorrow’s date. “Date” seems much more tangible.

I was curious, though, to know if there was a difference in how quickly Ruby could process the two. So I ran a test.

The First Test

I was in a Rails app, so I fired up script/console, and added the following code:

require 'benchmark' { 1000.times { puts } } { 1000.times { puts } }

The Results

What I found was really interesting.

I ran the test a couple of times, and the average processing time for was 104 ms. The average processing time for was 251 ms.

That means it took about two and a half times as long to get processed than

The Second Test

I was curious to see if those results would hold if I ran a more complicated test. So I made the processing a tiny bit trickier:

def month_name_t(month =
end { 1000.times { month_name_t } }

def month_name_d(month =
end { 1000.times { month_name_d } }

More Results

This time around, the difference was even more pronounced.

On average, month_name_t ( took 2 ms. And month_name_d ( took 80 ms.

So when we made the function just a bit more complex, it increased the processing time dramatically: took 40 times as long to process as

The Conclusion

When you’re processing Times and Dates in your app, and you don’t need to use the Date object for some reason, use Time.

To get updates when I post more, follow me on the Twitter machine.