As people spend more time with Ruby 1.9, JRuby, and Rubinius, we are seeing a lot more benchmarks. It has been a while since we published any metrics, so I thought now would be a good time to summarize our recent experience on some real projects. We chose to measure some different things, however:

• DPC. Developer Productivity, as judged by the Client. This is the percentage of iterations where the client felt that the developers were more productive in Ruby than they would have been with their second choice "Platform B."
• DPR. Developer Productivity, as judged by Relevance. Like above, but in Relevance's opinion.
• DP5. Is Developer Productivity in the Top 5 list of things we would like to have more of? In other words, a project with a high DPC and DP5 means that the client is happy with Ruby, but would be even more happy if Ruby was, um, Rubyer.
• CS5. Is Code Speed in the Top 5 list of things we would like to have more of?

Here's the numbers. The trends are not subtle.

            DPC      DPR      DP5      CS5
Project A:  100%     100%     100%     0
Project B:  100%     100%     100%     0
Project C:  100%     100%     100%     0
Project D:  100%     100%     100%     0

At this point, even caring about Ruby's language performance would be a premature optimization at the business process level. Ruby's runtime performance is a non-issue for a broad spectrum of applications. In fact, I believe that all of our customers would be even happier with a language that ran 50% slower than Ruby, if it also made the development team a mere 10% more productive.

Jay Fields blogged recently (and not for the first time) about managing gems within Rails projects. This is a problem a lot of people have wrestled with; there are close to a dozen plugins, rake tasks, uncommitted patches, and published hacks that attempt to provide a solution (and those are just the ones I know of).

FrozenGemsGenerator is the solution that we’ve been using on some projects at Relevance, and we’re happy enough with it that we’ll be using it more. It’s a rails generator, packaged as a gem, that gives your Rails app a private gem repository, fully self-contained, and manageable just like your system-wide repository (except using script/gem instead of gem).

$ sudo gem install frozen_gems_generator
$ script/generate frozen_gems
$ script/gem install money

script/gem supports all of the subcommands that the regular gem command does.

I haven’t yet implemented a solution for gems that install binary extensions. I’m very interested in suggestions for how best to solve that problem. Several of the other approaches have at least partial support for architecture-specific gems; the best may be Jeremy Voorhis’ CarryOn plugin, which is also the solution that’s closest in spirit to the FrozenGems approach. If you have ideas or suggestions about how architecture-specific gems should be handled, please add comments here or post them on our Trac instance.