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 On Wed, Apr 7, 2010 at 1:01 AM, Michael Koziarski <[email protected]>wrote: > > 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 :). > > > -- > Cheers > > Koz > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<rubyonrails-core%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
