Greg's Blog

Moving to Source Matters

2012-04-10T04:35:57Z

I've started a new blog called Source Matters. I've moved the one post that I had here from 2012--In My Toolkit: Midje--but have not yet decided whether to migrate the older posts. In the mean time, they will remain available here.

Thank you for reading this blog and I hope to see you at Source Matters.

Relative Performance of Symbol#to_proc in Popular Ruby Implementations

2010-11-16T16:34:33Z

When Rails 1.1 introduced Symbol#to_proc in 2006, many people, including me, embraced the convenience and elegance of being able to write code such as this:

post_ids = posts.map &:id

instead of the equivalent standard Ruby syntax:

post_ids = posts.map {|post| post.id}

Others pointed out that the Symbol#to_proc approach was much slower than using an explicit block. A commenter on this post on Josh Susser's blog, for example, shows a benchmark revealing Symbol#to_proc to be 3.4 times slower on one example.

In the intervening years, Symbol#to_proc has become part of standard distribution of Ruby 1.8.7 and Ruby 1.9. Being curious about its performance on current Ruby implementations, I constructed a simple benchmark and ran it on the Rubies that I have installed under RVM. My version of the benchmark measures performance of Symbol#to_proc when used with map on arrays of a variety of lengths.

The benchmark code and raw result data can be found here. The table below summarizes the results. Each cell shows the number of times slower that Symbol#to_proc is in comparison to using a block.

	10 Elements	100 Elements	1,000 Elements
Ruby 1.8.7	2.24	1.56	1.34
REE 1.8.7	2.49	1.93	1.66
Ruby 1.9.2	1.03	0.94	0.95
JRuby 1.5.3	7.22	3.18	3.61
Rubinius 1.1.0	5.82	7.55	6.86
MacRuby 0.7.1	6.86	9.80	9.96

In Ruby 1.9.2, the performance of the two forms is very close. In fact, Symbol#to_proc is actually faster for longer arrays.

What I found most interesting, though, was how much larger the performance penalty for using Symbol#to_proc is in JRuby, Rubinius, and MacRuby. I will keep that in the back of my mind when I'm writing code that may be used in those environments.

Release Announcement: has_enumeration 1.0.0

2010-11-08T15:24:46Z

This month marks five years since I left a career in embedded systems software development in a quest to reignite my passion for programming. I began my love affair with Ruby shortly thereafter. It was elegant and expressive. It was object-oriented and had closures. It was everything that I had been yearning for while programming in C for all those years.

There are times, though, when I have flashbacks to my C days. Consider this code snippet:

class Car < ActiveRecord::Base
  # Values of the color attribute
  RED = 1
  GREEN = 2
  BLUE = 3
end

car = Car.new(:color => Car::RED)
# ...
if car.color == Car::RED
  # ...
end

This reminds me of C-style #define constants and feels clunky. A popular variation is to use a Car::COLOR hash keyed by symbols representing the color names. The downside is that comparisons with the color values become even more verbose (e.g., Car::COLOR[:red]) and a typo in the color name is no longer caught as an unknown constant, leading to potentially hard to find bugs.

A different approach is to store the enumerated value as a string rather than an integer. Now the code looks nicer (if car.color == 'red') and the database performance is nearly identical if you use an enum column to represent the attribute. But, there is still the possibility of bugs from misspelled values.

Enter has_enumeration

Using the approaches described above to handle what is essentially an enumerated type stored in an ActiveRecord attribute has always struck me as lacking. Eventually I set out to approach the problem in more idiomatic Ruby way. The result is my has_enumeration gem.

Here is the car example again, using has_enumeration:

class Car < ActiveRecord::Base
  has_enumeration :color, :red => 1, :green => 2, :blue => 3
end

car = Car.new(:color => :red)
# ...
if car.color.red?
  # ...
end

The values of the enumeration are represented by symbols regardless of the underlying representation in the database. Predicates are provided for testing whether the enumerated attribute has a given value. The symbolic values work with query methods as well:

# Rails 2.x
Car.find(:all, :conditions => {:color => :red})

# Rails 3
Car.where(:color => :red)

When using Rails 3, has_enumeration plugs in at the Arel attribute level. This allows it to work seamlessly with code that directly manipulates Arel attributes and with plugins like meta_where that extend Arel's functionality.

To help catch coding errors, has_enumeration will raise an ArgumentError if you attempt to assign or query for a symbol that is not part of the attribute's set of values.

Getting More Information

You can find the source code and more examples of its use on the has_enumeration github project page.

I hope that you find this gem useful. Please let me know if you encounter any problems or if there is any additional functionality that would make it work better for you.

Arbitrary Reordering of Ruby Arrays

2010-11-07T21:06:50Z

Reordering an array in Ruby is easily accomplished with Array#sort as long as you can provide a block that can compare two elements of the array and indicate their relative ordering. But, what if determining the relative ordering of the elements is not as simple as using the equivalent of the <=> operator on the two elements? What if, say, you wanted to reorder an array of ActiveRecord objects to reflect the order in which their IDs were returned by your search engine?

For that, something like this would do the trick:

ranked_ids = Book.search_by_title('ruby')
books = Book.where(:id => ranked_ids).reorder_by(ranked_ids, &:id)

This assumes that Book.search_by_title returns an array of IDs that are ordered by their relevance to the search term. The corresponding objects are fetched from the database and then reordered to match the order returned by the search call.

Of course, reorder_by is not part of the standard Ruby library. We get to build it ourselves. Here is a first attempt:

module Enumerable
  def reorder_by1(order, &key_proc)
    order.map do |x|
      find {|obj| key_proc.call(obj) == x}
    end
  end
end

# Make sure it works...
describe Enumerable, "#reorder_by1" do
  before(:each) do
    @objects = [:a, :b, :c, :d, :e]
    @ordering = %w(e b c d a)
    @expected = [:e, :b, :c, :d, :a]
  end

  it 'reorders the objects in the desired order' do
    @objects.reorder_by1(@ordering, &:to_s).should == @expected
  end
end

reorder_by1 iterates through each key in the desired ordering and finds the first object for which key_proc returns that key. The spec passes, but benchmarking results show that it is very slow: with a 52-object array, 10,000 reorderings took 7.2 seconds. We can do better.

Let's start with computing the result of key_proc just once per element of the array:

module Enumerable
  def reorder_by2(order, &key_proc)
    indexed = map {|x| [key_proc.call(x), x]}
    order.map do |x|
      indexed.find {|pair| pair.first == x}.last
    end
  end
end

This version first makes (key, object) pairs and then searches those pairs for matching objects. This improves things significantly: the same benchmark now completes in 3.2 seconds. We are still using an O(n²⁾ algorithm, though. We can do better.

Here is the final version of reorder_by that looks up the corresponding objects in a hash rather than using a linear search:

module Enumerable
  def reorder_by(order, &key_proc)
    index_to_obj = inject({}) do |hash, obj|
      hash[key_proc.call(obj)] = obj
      hash
    end
    order.map do |x|
      index_to_obj[x]
    end
  end
end

This version clocks in at 0.7 seconds: a 10x improvement over the first version. I am satisfied with that result and no other optimizations come to mind. I would not be surprised, though, if it could be made at least a little faster.

I've posted the above code along with the benchmark setup to this gist. If you have ideas for making reorder_by faster, give it a try. If you come up with a faster version, I'd love to see your implementation!

Rujubu's View is now Greg's Blog

2010-11-07T19:37:41Z

This blog started its life as Rujubu's View in 2007 when my consulting company, Rujubu Consulting, was actively seeking business. When I relaunched the blog last month after a long period of inactivity (see Relaunching Rujubu's View), I was contemplating returning to active consulting. In preparation for that, I kept the blog's name and its URL on the rujubu.com domain.

Last week I decided to keep Rujubu Consulting on ice for the foreseeable future and accepted a new full-time position at a company (more on that later, perhaps). I am very interested in keeping this blog going, but no longer have a need to promote my consulting business. So, I have renamed it to "Greg's Blog" and have moved it to my personal domain.

Lazing: Lazy Enumerable Methods for Ruby 1.9

2010-10-24T18:27:07Z

The select_first approach I wrote about in Selecting Only What You Need addresses the need for a lazy version of select in a very specific use case. It solved the problem, but left me wanting a general solution.

I found a few blog posts and gems providing lazy versions of a subset of the methods defined in Enumerable. I was unsatisfied with them, though, primarily because of their clunky method names. I strongly believe that code should be easy to read aloud and names like lz_select, lazy_select, and select_lazy do not roll off the tongue.

Assuming side-effect-free blocks, the use of the lazy variant will not affect the end result: it is simply a performance optimization. Knowing that the method is lazy is not essential to understanding the meaning of the code and does not need to be called out so explicitly. Someone who is taking a closer look at the code may appreciate knowing about the laziness, but the code does not need to scream out "look, I'm lazy!" to first-time readers.

I prefer using the present participle form of the name to indicate the lazy variant. E.g., selecting is the lazy variant of select. For the casual reader, the meaning of the code is still clear without having to worry about laziness. To those looking more closely, the "ing" suffix hints that the operation is still in progress.

Implementing lazy variants of methods like select and map is fairly trivial in Ruby 1.9 using the block form of Enumerator.new. Here is the definition of selecting:

module Enumerable
  # Returns a lazy collection containing all elements of the collection
  # for which the provided block returns true.
  def selecting(&blk)
    Enumerator.new do |yielder|
      each do |item|
        yielder.yield item if blk.call(item)
      end
    end
  end
end

I have implemented lazy variants following this naming scheme for several of the methods found in Enumerable. They are packaged in a gem called lazing and the source can be found on github in my lazing project.

For now Lazing requires Ruby 1.9. If there is sufficient interest in support for 1.8.7, I will look into adding it.

Selecting Only What You Need

2010-10-22T19:48:56Z

A couple of weeks ago I was investigating a performance problem. New Relic RPM narrowed the search and code inspection identified the culprit. With the names changed a bit, the problem was:

items = candidates.select {|c| c.super_cool?}.first(5)

It looks innocuous, but, it turns out that super_cool? is expensive to compute and candidates has many members. In the common case where the first five super cool items are found within the first six or seven candidates, a lot of computation is wasted determining whether the other candidates are also super cool.

At times like this, I wish that Ruby's Enumerable module was inherently lazy like Clojure's sequence library. The code above would then be much more efficient: super_cool? would only be invoked enough times to satisfy the request for the first five super cool items. The remaining candidates would never be touched.

To approximate that behavior, I combined the select and first into a single method called select_first:

module Enumerable
  # Returns an array containing the first +n+ items for which the
  # provided block returns true.
  def select_first(n)
    results = []
    each do |item|
      results << item if yield item
      break if results.length == n
    end
    results
  end
end

This before-and-after example demonstrates that evaluation stops after the requested number of matches has been found:

# Wishing for laziness
>> a = (1..20)
 => 1..20 
>> a.select {|x| raise 'boom' if x == 6; x.odd?}.first(3)
RuntimeError: boom
    from (irb):14
    from (irb):14:in `select'
    from (irb):14:in `each'
    from (irb):14:in `select'
    from (irb):14

# select_first to the rescue
>> a.select_first(3) {|x| raise 'boom' if x == 6; x.odd?}
 => [1, 3, 5]

In this case, laziness is a virtue.

Relaunching Rujubu's View

2010-10-22T19:49:10Z

The former incarnation of this blog was stagnate. After more than a year and a half without any new posts, I took it down until I had something new to say. That was preferable to letting it become another neglected site collecting dust on the shelves of the World Wide Web.

As of today, Rujubu's View is back.

Why now? The past few months have been a period of renewal for me and I find myself very excited about Ruby and Rails again. RVM and Bundler have made it incredibly easy to experiment with and test on various Ruby interpreters and combinations of gems. I've been exploring Cucumber and finding it to be an extremely useful--and enjoyable--companion to RSpec.

The release of Rails 3, of course, has given me a big shot of enthusiasm. I have been using it full-time since Beta 3 and am really liking the refinements and new features it brings to the table. The changes to ActiveRecord, in particular the addition of Active Relation, have allowed me to refactor some ugly, complex code to be much more readable and maintainable. The new routing system has also been a joy to work with.

And then there was the release of Ruby 1.9.2. This is the first 1.9 release that I feel comfortable putting into production. Now that the mysql2 gets rid of the encoding issues that showed up with the old mysql gem and Ruby 1.9, I'll be doing that very soon.

I'm inspired by the projects and releases I mentioned above as well as a lot of others. It's an exciting time to be part of the Ruby and Rails community! I have several projects and ideas for articles in the queue and I'll be posting them as they come to fruition.

Welcome back. We're going to have fun.