(Rails3 latest git master)
Subject says it. I'm trying to figure out how to use erubis features
described here: http://www.kuwata-lab.com/erubis/users-guide.05.html#rails,
especially preprocessing. My question is, where do I place the
Erubis::Helpers::RailsHelper.preprocessing=true
Not in application.rb, at that point the object does not exist yet it
seems. I wonder why I don't see ANY mention whatsoever of such an
important feature like erubis preprocessing when someone writes about
"Rails 3 x-times faster"? Or about what it means that erubis is in
Rails 3 now? Or did I (i.e. Google) overlook some blog post 
Not in application.rb, at that point the object does not exist yet it
seems. I wonder why I don't see ANY mention whatsoever of such an
important feature like erubis preprocessing when someone writes about
"Rails 3 x-times faster"? Or about what it means that erubis is in
Rails 3 now? Or did I (i.e. Google) overlook some blog post
The preprocessing functionality in Erubis is a little brittle. It
relies on custom implementations of helpers like link_to which can be
evaluated outsite the context of a request / response and statically
be copied into the template source. It's kind of a neat trick, but it
won't work out of the box with rails 3 unless the erubis lib gets
updated or other people ship alternative erubis compilers which do
that kind of thing.
In reality, the use of erubis in rails 3 wasn't for performance gains
(which were relatively minor) but because it's a much nicer API to
extend and write our own customisations to the rendering phase.
Specifically building the XSS-escaping was quite trivial to do with
erubis but was a huge amount of monkeypatching when I first tried in
with erb.
Don't expect magical performance gains or anything, it's just a nicer
upstream gem for us to use :).
Yeah,
Essentially, the way preprocessing works is by providing a completely different (static) helper to Erubis at compile-time. You might think of link_to as static (if you use it that way), but it actually does a whole slew of request-specific things. Over time, helpers like link_to actually become more dynamic as Rails tries to reduce the tedium that comes from having to manually care about request-specific concerns.
A simple case: the link_to helper use the current environment’s host name, the SCRIPT_NAME (in the case where Rails is nested inside of Rack::UrlMap or other Rack mapping layer) and the :controller/:action/:id from the current request (which is how url_for(:action => :index) works. In short, the number of caveats in even something as simple as link_to is large.
If you were able to make a purely-static version of link_to, it would be so simplified that the vast majority of the performance improvement would likely apply to using that helper in a dynamic context. And of course, we can always improve the performance of helpers like link_to much more (a focus of 3.0 and even more in future versions of Rails).
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
Okay thanks! That saves me LOTS of time trying to find things out by
looking at the source, which is nice but which I try to avoid (since
there is so much of it to look at these days, and esp. library- and
framework code being so fragmented and full of optimizations good for
many things but not readability).