I''d like to get some opinion on the following issue: a large part of /link_to/ speed is lost in calling /stringify_keys/ on the html_options hash and /symbolize_keys/ on the options hash. Why can''t we request coders to always use symbols for the options hash, and always strings on the html_options hash? It would be easy to state that in the documentation of link_to and url_for. Regards, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails-core/attachments/20050617/04ed5fbf/attachment.html
Stefan Kaes wrote:> Why can''t we request coders to always use symbols for the options > hash, and always strings on the html_options hash?One problem with this is that the routing code merges the current request''s path parameters with the url_for options in order to obtain sensible recall behavior. (ie. url_for :action => ''index'' remembers the current controller.) Merging strings against symbols won''t work too well. An alternative is to have routing create a hash which uses symbols, and then merge it into the parameters hash. When a URL is generated, the unmerged hash with symbols will be used to obtain the default values. This will hit us with one more call to stringify_keys, however benchmarks with a typical hash have shown that each call will take approximately 0.0161462068557739 ms. Hopefully that is acceptable to everyone. ;-) Any comments? Cheers, Nicholas
Nicholas Seckar wrote:> Stefan Kaes wrote: > >> Why can''t we request coders to always use symbols for the options >> hash, and always strings on the html_options hash? > > > One problem with this is that the routing code merges the current > request''s path parameters with the url_for options in order to obtain > sensible recall behavior. (ie. url_for :action => ''index'' remembers > the current controller.) Merging strings against symbols won''t work > too well. > > An alternative is to have routing create a hash which uses symbols, > and then merge it into the parameters hash. When a URL is generated, > the unmerged hash with symbols will be used to obtain the default values. > > This will hit us with one more call to stringify_keys, however > benchmarks with a typical hash have shown that each call will take > approximately 0.0161462068557739 ms. Hopefully that is acceptable to > everyone. ;-) > > Any comments? >I would prefer adding a new function to AbstractRequest def path_parameter_symbols_hash @path_parameter_symbols_hash ||= path_parameters.symbolize_keys end so that one only gets a performance hit when using link_to with hash arguments, since I am not using it at all. I assume Request gets instantiated for each request. Regards, Stefan