The first Living on the Edge covered some of the API changes since Rails 2.1, and this time round, I’m going to cover the performance improvements as promised.
Jumping right in…
Faster Erb templates
Jeremy Kemper has made the Erb processing more efficient, especially the concat and capture helper methods.
The “special” Erb _erbout has been replaced with an instance variable, which allows for:
better (memory) performance because bindings are no longer being passed around,
fewer evals which are usually expensive,
there’s no need to slice the _erbout variable when you can swap in a new (string) buffer, and
the buffer is actually available via a output_buffer reader and writer methods (so you can override it if you want).
Partial template initialization and JavaScript helpers have been refactored and optimized for speed and efficiency by Jeremy Kemper. These are but a few of the optimizations Jeremy has been committing recently. Be sure to check out some of the commits to Rails (or for that matter, any quality Open Source project) – you could learn something!
The RecordIdentifier has been sped up by some simple use of memo-ization, thus reducing the number of inflections performed, among other things. The RecordIdentifier is used widely in cache keys, partial template paths, and in most places where you identify an ActiveRecord model without caring about its actual id.
Update: Oops my bad, this change was later reverted in 6573f6a.
The various cache stores in the ActiveSupport::Cache module are now lazy loaded – this means that they are only required when you actually start using them.
As Gregg Pollack mentioned a week or so ago, I’ll be keeping a weekly-or-so column about noteworthy changes on edge Rails. This is the first time Living on the Edge (of Rails) is appearing on the official Ruby on Rails weblog, so you’ll have to bear with my short introduction.
Living on the Edge is a weekly column I used to put up on my own blog after some prodding by Gregg Pollack of Rails Envy way back in December of 2007. I used to be a rather active Rails contributor back then so it was a no-brainer. Gregg and Jason were awesome enough to feature it weekly in their podcast.
And now it’s here, so try your best to be a tough crowd so I can tune these blog posts so that they are actually useful to you – when I was blogging these on my tiny personal blog it wasn’t that vital but now the audience is significantly larger. Leave your suggestions and criticisms in the comments – they are greatly appreciated!
Anyway, there’s been a ton of new features, API changes and performance improvements in the past 2 weeks or so since Rails 2.1 was released, so rather than dumping all into one mega-post, I’ve decided to break it into 2 posts for new features/API changes and performance improvements. In this post, I’m gonna talk about some of the new features and API changes.
Minor API changes
Let’s start jump straight in with some minor API changes.
link_to now takes a block
The link_to helper now takes a block argument for those occasions when you have really long hyperlink text with variables in them:
<% link_to(@profile) do %>
<strong><%= @profile.name %></strong> -
<span>Status: <%= @profile.status %></span>
<% end %>
Association macros now accept a :validate option like so:
class Anime > ActiveRecord::Base
has_many :characters, :validate => true
end
This tells ActiveRecord to validate the characters association when saving your Anime model – just like how :validates_associated works. The default is false, which is the current behavior in Rails 2.1 and earlier, so no need to fret. This works for all the other association macros as well (has_one, belongs_to, has_and_belongs_to_many).
Thumbs up to Jan De Poorter and Pratik Naik for this, which also fixes a nasty bug.
ActiveSupport::StringInquirer and convenience Rails.env.development? methods
David Heinemeier Hansson (henceforth abbreviated as DHH – sorry!) recently added an ActiveSupport::StringInquirer String subclass that allows you to do this:
An immediate use of this is when you are checking the environment your app is running in: Rails.env is wrapped in a StringInquirer so you can use query methods like Rails.env.development? and Rails.env.production?.
Core extensions: Object#present? and Enumerable#many?
DHH also added some core extensions that while trivial, could make your code more readable. First up is Object#present?, which is essentially !Object#blank?
DHH was inspired by Jay Fields when he committed this bit of syntatic sugar: you can now write your tests (Test::Unit) in declarative block style like so:
test "an anime should be invalid if any of its characters are invalid" do
# Your usual test code here.
end
I seldom use Test::Unit (except when submitting Rails patches) and prefer RSpec – this declarative style of writing tests is definitely more readable.
All Rails-generated test stubs now use this new syntax.
Jeremy Kemper has been hard at work optimizing and improving the performance of Rails, so it’s no surprise that he has also introduced a new type of integration test: the performance test.
You can use the performance test generator (added by Pratik in 23232a) to generate a performance test stub.
script/generate performance_test LoginStories
Running the performance test requires ruby-prof >= 0.6.1, which is still unreleased but you can get at it the development version by checking out the source and installing the gem yourself (I suggest you get Jeremy’s fork of ruby-prof for now). It’s interesting to note that with the 0.6.1 release, ruby-prof supports profiling tests cases written using Test::Unit.
Moving on… Put in some test code (request a few controller actions – whatever user story you want to test performance of) and run the test. You’ll get output like this (together with the usual ruby-prof profiling output in the test/tmp/performance directory of your Rails app):
> ruby performance/login_stories_test.rb
Loaded suite performance/login_stories_test
Started
LoginStoriesTest#test_homepage (32 ms warmup)
process_time: 11 ms
memory: unsupported
objects: unsupported
.
Finished in 0.870842 seconds.
The memory and objects results are “unsupported” because I haven’t patched my Ruby interpreter for memory profiling support. You’d need certain Ruby interpreter patches to enable memory and GC profiling. I wish I could tell you more about how to do so, but I’m treading unfamiliar ground here. There are some details here on how to patch Ruby for memory profiling. I leave it for wiser folks to explain how to do this :)
That’s it so far for new feature/API changes in Rails since Rails 2.1 – performance improvements are coming up in the next post and I’ve also intentionally left out mention of the Rack support that has been partially merged into edge.
If there were any errors or you have any suggestions on how to make this column better, please point them out in the comments. Any info on patching your Ruby interpreter for memory profiling support is also greatly welcome. If I’ve left out anything that I’d considered not noteworthy enough but you disagree, let me know in the comments too.
GitHub has now officially launched and Rails is right there at the premiere. The Rails repository now lives at rails/rails and you can check it out with:
git clone git://github.com/rails/rails.git
If you don’t have git, or don’t enjoy running it on your platform, you need not fear. We’ve set up an automated task to produce a zip file of Rails Edge that’ll be kept up to date all the time: http://dev.rubyonrails.org/archives/rails_edge.zip. This is also what we’ve made the new rake rails:freeze:edge use.
This also means that development on the Subversion repository has stopped and will no longer be kept up to date. We’ll keep the Subversion repository around for some time for people to transition off svn:externals, though. But if you want the latest edge, you’ll have to use either git or the new zip files.
We’ll also soon go live with our new ticket management system, which will be running on a new version of Lighthouse. When that happens, the Trac installation will follow the Subversion repository into legacy. We’ll still keep it around so we can work through all the patches and tickets that are there, but everything new will happen on the Lighthouse setup.
We hope you’ll enjoy this upgrade to the Rails collaboration infrastructure. We’re really looking forward to the onslaught of marvelous patches that the Git lords have promised us will flow from the mountain now.
We’ve been preparing for Rails to move the official source repository from Subversion to Git for some time now and it seems that it’ll happen over the next week or so. The premiere will happen alongside the official launch of Github.
The move will also mean that we’re going to be switching ticket tracking to Lighthouse. So now both our repository and ticket tracking will be powered by Rails applications, which is a nice bonus treat.
When the move happens, we’ll freeze the existing Subversion repository and the Trac installation. Both will live on for a long time to come, but will be entirely deprecated. This means that your existing svn:externals will not break, but if you want the latest edge, you’ll have to get it from the new git repository.
So now is a great time to learn more about Git in anticipation of this move. I recommend starting with the Git for SVN’ers crash course.
The extracted adapter gems are now available for install from the gems.rubyonrails.org server. Say you want the Oracle adapter installed, you just do gem install activerecord-oracle-adapter. All the extracted gems are:
activerecord-firebird-adapter
activerecord-frontbase-adapter
activerecord-openbase-adapter
activerecord-oracle-adapter
activerecord-sqlserver-adapter
activerecord-sybase-adapter
The mysql, postgresql, and sqlite adapters are still included in Rails core.
These will be released to the standard Ruby repository alongside Rails 2.0 when that reaches final.
