litany against fear

RailsConf 2009 What Makes Ruby Go An Implementation Primer

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk was presented by Charles Nutter and Evan Phoenix.

Method Calls. What happens? Evaluate receiver and arguments, look up method named ‘foo’ (walking up the class heirarchy), and call it. Lookup is the most expensive part. There has to be some sort of method cache because walking through the different classes is really expensive. This involves checking for a cached method and ensuring the class hasn’t changed since the cache was saved. Huge deal for performance with dynamic method invocation. 80% faster typically with a method cache.

Tons of things can affect the cache: def / undef, Module#define_method, etc. Object#extend is the huge problem. Used for mixins with modules and adding methods all the time in Ruby. How does extend affect the cache? In 1.8/1.9 the entire cache is cleared, but with JRuby (and somewhat with Rubinius) it’s localized. Extending a module has some massive performance implications. A little increase in syntatic sugar can lead to pretty huge slowdowns. It’s still definitely useful, but it has to be used with caution or in a different manner.

Constant lookup! Same deal, lots of searching through the heirarchy. Cached at lookup site, and they are globally cached across all Ruby implementations. So basically, don’t redefine constants at runtime or frequently.

Options Argument: Basically passing a hash at the end of an argument. Forcing Ruby to create the hash for you, or passing no arguments at all hurts performance.

obj.run rescue nil: eating exceptions in one line. Happens for two reasons: dirty way to fix a problem at 1am, and possibly by design though extremely rare. The big problem: StandardError has 101 subclasses, and you probably want to know about what happened. Best thing to do: throw it into a logger.

autoload: Delay code loading until some later point. Lots of problems though…for one, it’s completely thread unsafe. Inherently broken with threads in all implementations. It doesn’t actually call #require, so you can’t autoload gems. Plenty of alternatives though: pretend to go single-threaded, pay the cost upfront

super: lots of different ways to use this keyword. One really strange behavior: blocks tacked onto a super call will be passed up implicitly to the superclass. Parens work really strangely, if you don’t specify them on super call it will use local variables that may have changed in lines before.

To wrap up: simpler code is the better code. Think twice about the fancy features of Ruby and how it might affect your app.