It's ok, as long as speed is at least on par with the other existing
i18n plugins, then we're on the right track and can incrementally
improve.
> Note that the benchmarks were done on a powerful machine with more RAM than
> most of us use on their servers. Also, let's not forget that I didn't even
> load Rails and therefore AS doesn't do it's multibyte magic which seriously
> slows down any string processing.
(I don't know why you keep saying this.)
> However, I do agree that it's not a real show stopper since template
> rendering isn't the bottleneck of current Rails apps. My concern is that
> this is the fastest/default i18n processing for Rails and once again we are
> affecting the overall performances.
Template rendering is, actually, the bottleneck for most Rails apps.
> As you said, this shouldn't be noticeable in most cases but I believe that
> we can profile the code and optimize it to make it at least twice as fast.
By all means :) Anyone have the time and inclination to do a bit of
performance work before (or at) RailsConf.eu?
Best,
jeremy
It's ok, as long as speed is at least on par with the other existing
On Wed, Aug 27, 2008 at 8:15 AM, Matt Aimonetti <mattai...@gmail.com> wrote:
> Hi Josh,
>
> Thanks for taking the performance report quite seriously. I understand you
> want to release Rails 2.2 for Rails Conf Europe and that won't give anybody
> enough time to fix the speed issues.
>
> I also realize that it's party my fault since I raised this concern a while
> back and promised some benchmarks which I only delivered today :(
i18n plugins, then we're on the right track and can incrementally
improve.
(I don't know why you keep saying this.)
> Note that the benchmarks were done on a powerful machine with more RAM than
> most of us use on their servers. Also, let's not forget that I didn't even
> load Rails and therefore AS doesn't do it's multibyte magic which seriously
> slows down any string processing.
Template rendering is, actually, the bottleneck for most Rails apps.
> However, I do agree that it's not a real show stopper since template
> rendering isn't the bottleneck of current Rails apps. My concern is that
> this is the fastest/default i18n processing for Rails and once again we are
> affecting the overall performances.
By all means :) Anyone have the time and inclination to do a bit of
> As you said, this shouldn't be noticeable in most cases but I believe that
> we can profile the code and optimize it to make it at least twice as fast.
performance work before (or at) RailsConf.eu?
Best,
jeremy
Right, we discussed it earlier: Multibyte is slow, especially compared
to Yehuda's superfast extension. Multibyte is not baked into String,
though, and doesn't slow down any string processing.
>> > However, I do agree that it's not a real show stopper since template
>> > rendering isn't the bottleneck of current Rails apps. My concern is that
>> > this is the fastest/default i18n processing for Rails and once again we
>> > are
>> > affecting the overall performances.
>>
>> Template rendering is, actually, the bottleneck for most Rails apps.
>
> Sorry, I didn't express myself correctly, what I meant was that at this
> level it won't really affect the template rendering (other stuff are way
> slower) but that's still a performance hit.
>
>>
>> > As you said, this shouldn't be noticeable in most cases but I believe
>> > that
>> > we can profile the code and optimize it to make it at least twice as
>> > fast.
>>
>> By all means :) Anyone have the time and inclination to do a bit of
>> performance work before (or at) RailsConf.eu?
>
> I won't be in Berlin, but I'll certainly my best to benchmark a bit more and
> see how we could improve the results. (I'll also try to benchmark Rails
> directly)
Cool. I'm sure we can get this blazing fast.
Best,
jeremy
I tried to change a bit #interpolate, instead of use StringScan I used
regexps in this way:
values.inject(string) do |memo, (pattern, value)|
memo.gsub(/\{\{#{pattern}\}\}/, value.to_s)
end
This portion of code is just a bit faster than actual implementation
(1.16x), but the whole method increase performance of 1.05x.
It's just a quick implementation, surely not good, but it could give
some hints to you, guys.
I posted the code, benchmark and results as gist:
http://gist.github.com/7775
Best,
-luca
--
blog: www.lucaguidi.com
Nice, Luca. You can speed this up further by doing a single gsub:
MATCH = /(\\\\)?\{\{([^\}]+)\}\}/
result = string.gsub(MATCH) do
escaped, pattern, key = $1, $2, $2.to_sym
if escaped
pattern
elsif INTERPOLATION_RESERVED_KEYS.include?(pattern)
raise ReservedInterpolationKey.new(pattern, string)
elsif !values.include?(key)
raise MissingInterpolationArgument.new(pattern, string)
else
value[key].to_s
end
end
# untested ;)
Best,
jeremy
I updated the code and benchmark gist results: http://gist.github.com/7775
PS: I attached a patch for Backend::Simple#interpolate:
http://gist.github.com/7775
Best,
-luca
--
blog: www.lucaguidi.com
Pro-Netics: www.pro-netics.com
Sourcesense - making sense of Open Source: www.sourcesense.com
Cool :)
I've applied this and created a ticket for Rails
I think #interpolate even reads better with StringScanner removed.