Living on the Edge (or what's new in Edge Rails) #2 - Performance improvements
Posted by Chu Yeow June 25, 2008 @ 04:24 PM
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 eval
s which are usually expensive, - there’s no need to slice the
_erboutvariable when you can swap in a new (string) buffer, and - the buffer is actually available via a
output_bufferreader and writer methods (so you can override it if you want).
Relevant changesets: 933697a - 0bdb7d3 - 4d4c8e2
Faster partials and JavaScript helpers
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!
Relevant changesets: partials – JavaScript helpers
RecordIdentifier methods speedup
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.
Relevant changesets by Jeremy Kemper: c1a9820 – 566d717
Lazy load cache and session stores
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.
Lazy loaded caches got reverted
http://github.com/rails/rails/commit/6573f6a4bc1c2ebd26e0b4b3ef9fe1cde3219354
Still much debate on the best technique to use to lazy load rails classes.
+1 for faster partials and erb processing, RecordIdentifier brought up to speed… These will speed up all requests.
Sounds pretty good, any benchmarks available?
Re the JS helper, most of them not being Unobtrusive I wish they would disappear quickly :(
Good job guys
-Matt
Goon news and Thumbs UP!
@Matt Aimonetti or… you could just not choose not to use the js helpers. I find them extremely useful and I’m glad to see them being improved.
I don’t know where the place to comment on this is, but the changes to eager loading strike me as very postgres-focused and poorly thought out. The switch away from LEFT JOIN to multiple SELECT queries seems to be the kind of thing an applications developer would do – and the sort of thing a DBA would shudder over. I’ve at least one counter-example; in mysql, with MyISAM engine-based tables, the LEFT JOIN approach is a clear performance win over SELECT FROM t1,t2, particularly if ORDER is applied to the query.
Where is this sort of thing properly discussed? I’d like to be involved – at least so my understanding of the motivations improves, and perhaps to pick up on some technical aspects I may have missed.
I am using Simply Rails 2 to learn how to develop web apps. Going through the book, I was instructed to use the script/generate model command, but the migration file I ended up with, instead of being 001_create_stories.rb, I got 20080708204721_create_stories.rb . Am I doing something wrong or is this a new convention. I am using Instant Rails for development environment
Thanks, Brian
Brian: it’s the new convention. For a good summary of what’s changed in Rails 2.1, head over to peepcode.com. They sell a PDF book that covers this and other stuff.