Question

First of all, I know how extend and include work, and what they’re usually used for etc. Whether it is a good idea or not is not part of my question.

My question is: how expensive is extend? It’s a common Javascript technique to extend instances and singleton objects. One could do something similar in Ruby, but would it be slow if used on a lot of objects?

Answer 1

Let’s see what happens in Ruby 1.9.3-p0 if you call extend on an object:

/* eval.c, line 879 */
void
rb_extend_object(VALUE obj, VALUE module)
{
    rb_include_module(rb_singleton_class(obj), module);
}

So the module is mixed into the singleton class of the object. How costly is it to fetch the singleton class? Well, rb_singleton_class_of(obj) in turn calls singleton_class_of(obj) (class.c:1253). That one returns immediately if the singleton class was accessed before (and thus already exists). If not, a new class is created by make_singleton_class which is not too expensive as well:

/* class.c, line 341 */
static inline VALUE
make_singleton_class(VALUE obj)
{
    VALUE orig_class = RBASIC(obj)->klass;
    VALUE klass = rb_class_boot(orig_class);

    FL_SET(klass, FL_SINGLETON);
    RBASIC(obj)->klass = klass;
    rb_singleton_class_attached(klass, obj);

    METACLASS_OF(klass) = METACLASS_OF(rb_class_real(orig_class));
    return klass;
}

This is all O(1).
Afterwards, rb_include_module (class.c:660) is called, which is O(n) regarding the number of modules already included by the singleton class because it needs to check whether the module is already there (there will usually not be many included modules in the singleton class, so this is okay).

Conclusion: extend is not a very expensive operation so you can use it often if you want to. The only thing I could imagine is that the resolution of method calls to the instance after the extend could be a bit more complex, as one additional layer of modules needs to be checked. Both is less of a problem if you know that the singleton class already exists. In that case, extend introduces almost no additional complexity.
However, dynamically extending instances can lead to very unreadable code if applied too extensively, so take care.

This small benchmark demonstrates the situation regarding performance:

require 'benchmark'

module DynamicMixin
  def debug_me
    puts "Hi, I'm %s" % name
  end
end

Person = Struct.new(:name)

def create_people
  100000.times.map { |i| Person.new(i.to_s) }
end

if $0 == __FILE__
  debug_me = Proc.new { puts "Hi, I'm %s" % name }

  Benchmark.bm do |x|
    people = create_people
    case ARGV[0]
    when "extend1"
      x.report "Object#extend" do
        people.each { |person|
          person.extend DynamicMixin
        }
      end
    when "extend2"
      # force creation of singleton class
      people.map { |x| class << x; self; end }
      x.report "Object#extend (existing singleton class)" do
        people.each { |person|
          person.extend DynamicMixin
        }
      end
    when "include"
      x.report "Module#include" do
        people.each { |person|
          class << person
            include DynamicMixin
          end
        }
      end
    when "method"
      x.report "Object#define_singleton_method" do
        people.each { |person|
          person.define_singleton_method("debug_me", &debug_me)
        }
      end
    when "object1"
      x.report "create object without extending" do
        100000.times { |i|
          person = Person.new(i.to_s)
        }
      end
    when "object2"
      x.report "create object with extending" do
        100000.times { |i|
          person = Person.new(i.to_s)
          person.extend DynamicMixin
        }
      end
    when "object3"
      class TmpPerson < Person
        include DynamicMixin
      end

      x.report "create object with temp class" do
        100000.times { |i|
          person = TmpPerson.new(i.to_s)
        }
      end
    end
  end
end

Results

           user     system      total        real
Object#extend                             0.200000   0.060000   0.260000 (  0.272779)
Object#extend (existing singleton class)  0.130000   0.000000   0.130000 (  0.130711)
Module#include                            0.280000   0.040000   0.320000 (  0.332719)
Object#define_singleton_method            0.350000   0.040000   0.390000 (  0.396296)
create object without extending           0.060000   0.010000   0.070000 (  0.071103)
create object with extending              0.340000   0.000000   0.340000 (  0.341622)
create object with temp class             0.080000   0.000000   0.080000 (  0.076526)

Interestingly, Module#include on the metaclass is actually slower than Object#extend, although it does the exact same thing (because we need special Ruby syntax to access the metaclass). Object#extend is more than twice as fast if the singleton class already exists. Object#define_singleton_method is slowest (although it can be cleaner if you only want to dynamically add a single method only).

The most interesting results are the bottom two, however: Creating an object and then extending it is nearly 4 times as slow as only creating the object! So if you create a lot of throwaway objects in a loop, for example, it might have a significant impact on performance if you extend every single one of those. It is much more efficient here to create a temporary class that includes the mixin explicitely.