[ruby-core:28546] Re: [Feature #905] Add String.new(fixnum) to preallocate large buffer

Hi,

2010/3/5 Kornelius Kalnbach <[e-mail]>:
> JRuby, for example,
> concats strings almost twice as fast in this benchmark:
>
> require 'benchmark'
>
> N = 10_000_000
> Benchmark.bm 20 do |results|
>  results.report 'loop' do
>    N.times { }
>  end
>  results.report "'' <<" do
>    s = ''
>    N.times { s << '.' << 'word' }
>  end
> end
>
> ruby19 string_buffer.rb
>                          user     system      total        real
> loop                  1.240000   0.010000   1.250000 (  1.255154)
> '' <<                 5.820000   0.060000   5.880000 (  5.889959)
>
> jruby string_buffer.rb
>                          user     system      total        real
> loop                  0.584000   0.000000   0.584000 (  0.488000)
> '' <<                 2.900000   0.000000   2.900000 (  2.900000)


I wonder why such a simple loop is slower than jruby...?

I retested.

  ruby19
                            user     system      total        real
  loop                  2.100000   0.000000   2.100000 (  2.095623)
  '' <<                11.720000   0.040000  11.760000 ( 11.768111)

  jruby
                            user     system      total        real
  loop                  2.263000   0.000000   2.263000 (  2.228000)
  '' <<                10.193000   0.000000  10.193000 ( 10.193000)

Ko1 told me that GC makes the second benchmark slower than JRuby.
In MRI, a string literal is duplicated whenever evaluated.
I moved the literals out of the loop:

  results.report "'' <<" do
    s = ''
    s1, s2 = '.', 'word'
    N.times { s << s1 << s2 }
  end

  ruby19
                            user     system      total        real
  '' <<                 6.810000   0.040000   6.850000 (  6.851979)

  jruby
                            user     system      total        real
  '' <<                 7.159000   0.000000   7.159000 (  7.126000)

Indeed, there is room for optimization in MRI, but in this case,
it is not in string concatenation, I guess.

-- 
Yusuke ENDOH <[e-mail]>