On Thu, Jun 18, 2009 at 3:08 AM, Robert D.[email protected]
wrote:
   a += b
  end
 end
 a = “Ruby Rules Re Rowld”
 bench.report “<<” do
  N.times do
   a += b
  end
 end
end
Someone else noted the += in the << section, but there’s another
issue: the “a” string is initialized only once for both rehearsal
and actual runs, since the body of the bmbm block is only executed
once to prepare the reports. If you modify it to put the a
initialization into the report blocks, it behaves more like you’d
expect. Here’s a run with JRuby, with the bmbm above, “a” init fix,
“<<” fix, and 5 iterations (only last iteration shown):
Rehearsal --------------------------------------
+= 0.343000 0.000000 0.343000 ( 0.343000)
<< 0.001000 0.000000 0.001000 ( 0.001000)
----------------------------- total: 0.344000sec
user system total real
+= 0.343000 0.000000 0.343000 ( 0.343000)
<< 0.001000 0.000000 0.001000 ( 0.001000)
Here’s JRuby all interpreted (no JIT compilation to bytecode):
Rehearsal --------------------------------------
+= 0.345000 0.000000 0.345000 ( 0.345000)
<< 0.002000 0.000000 0.002000 ( 0.002000)
----------------------------- total: 0.347000sec
user system total real
+= 0.356000 0.000000 0.356000 ( 0.356000)
<< 0.002000 0.000000 0.002000 ( 0.002000)
The numbers are basically the same because this bench is almost
completely limited by object allocation/GC and to a lesser extent
String performance for the two operations. But obviously << is faster
because it’s growing the backing buffer for a single String rather
than creating a new one each time and copying the contents of the
previous string.
Here’s the same in Ruby 1.9:
Rehearsal --------------------------------------
+= 0.260000 0.510000 0.770000 ( 0.766618)
<< 0.000000 0.000000 0.000000 ( 0.002294)
----------------------------- total: 0.770000sec
user system total real
+= 0.250000 0.510000 0.760000 ( 0.771757)
<< 0.000000 0.000000 0.000000 ( 0.002235)
This was JRuby 1.4.0dev on current Apple Java 6.
<< Â 52.953000 Â 0.000000 Â 52.953000 ( 52.953000)
Server would perform a lot better here, but I suspect the fact that
the “a” string was never re-initialized and just kept getting bigger
was the main reason for this peculiar result.
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
Rehearsal --------------------------------------
+= Â 0.360000 Â 0.020000 Â 0.380000 ( Â 0.406038)
<< Â 1.040000 Â 0.130000 Â 1.170000 ( Â 1.209839)
----------------------------- total: 1.550000sec
    user   system    total     real
+= Â 1.770000 Â 0.230000 Â 2.000000 ( Â 2.056577)
<< Â 2.410000 Â 0.240000 Â 2.650000 ( Â 3.456429)
I’m not sure why Ruby 1.9 did better here, but it could be that we
grow strings at different rates and so our strings get larger faster.
At any rate, in the fixed benchmark things look a lot better.