From: Eric Hodel <drbrain@...7.net>
Date: 2011-07-06T13:14:04+09:00
Subject: [ruby-core:37821] [Ruby 1.9 - Bug #4962][Assigned] come back gem_prelude!


Issue #4962 has been updated by Eric Hodel.

Status changed from Open to Assigned

I have made three runs of `make benchmark` using the following revisions of ruby:

ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.8.0]

ruby 1.9.3dev (2011-07-05 trunk 32413) [x86_64-darwin10.8.0]

The benchmark bm_vm_thread_mutex3.rb was disabled as it presented an an extreme outlier for 1.9.2p180.

I took the total time it took all benchmarks to run.

The first run is with the ruby checkout

1.9.2:	204.890	206.312	209.319
1.9.3:	210.793	215.815	214.773
diff:	5.903	9.503	5.454

(For diff, smaller is better)

The second run is with --disable-gems for 1.9.3.  I modified RUNRUBY in Makefile:

RUNRUBY = $(MINIRUBY) $(srcdir)/tool/runruby.rb --extout=$(EXTOUT) $(RUNRUBYOPT) -- --disable-gems 

1.9.2:	215.472	206.452	205.110
1.9.3:	201.837	194.694	191.747
diff:	-13.635	-11.758	-13.363

The third run is with my changes to delay work in rubygems.rb:

1.9.2:	208.982	211.249	208.637
1.9.3:	198.714	201.984	198.293
diff:	-10.268	-9.265	-10.344

Here are the average differences from 1.9.2-p180:

stock ruby trunk:	6.953
--disable-gems:	-12.919
rubygems patches:	-9.959

Is the slowdown of 2.96 seconds between --disable-gems and my fixes across all benchmarks acceptable?

Should I look for additional improvements?

----------------------------------------
Bug #4962: come back gem_prelude!
http://redmine.ruby-lang.org/issues/4962

Author: Yusuke Endoh
Status: Assigned
Priority: Normal
Assignee: Eric Hodel
Category: lib
Target version: 1.9.3
ruby -v: -


Hello, rubygems developers

Kosaki-san noticed that 1.9.3 is slower than 1.9.2 on many benchmarks.
http://www.atdot.net/sp/view/5qunnl

I investigated and found that the cause is the lack of gem_prelude.rb.

Loading rubygems seems to create many objects and keep the references
to them.  See below:


$ ruby -ve 'GC.start; p ObjectSpace.count_objects[:TOTAL]'
ruby 1.9.2p180 (2011-02-18 revision 30909) [i686-linux]
9821

$ ./ruby -ve 'GC.start; p ObjectSpace.count_objects[:TOTAL]'
ruby 1.9.3dev (2011-07-01 trunk 32356) [i686-linux]
19638

$ ./ruby --disable-gems -ve 'GC.start; p ObjectSpace.count_objects[:TOTAL]'
ruby 1.9.3dev (2011-07-01 trunk 32356) [i686-linux]
9821


The number of live objects is proportional to the cost of GC mark phase.
You can actually confirm the performance degradation with the following
benchmark script:

  require 'tempfile'
  max = 200_000
  str = "Hello world!  " * 1000
  f = Tempfile.new('yarv-benchmark')
  f.write str
  GC::Profiler.enable
  max.times{
    f.seek 0
    f.read
  }
  p GC::Profiler.total_time


$ time ruby -v bm_io_file_read.rb
ruby 1.9.2p180 (2011-02-18 revision 30909) [i686-linux]
0.7280460000000308

real    0m3.965s
user    0m2.940s
sys     0m1.024s

$ time ./ruby -v bm_io_file_read.rb
ruby 1.9.3dev (2011-07-01 trunk 32356) [i686-linux]
1.396088000000029

real    0m4.786s
user    0m3.716s
sys     0m1.060s

$ time ./ruby --disable-gems -v bm_io_file_read.rb
ruby 1.9.3dev (2011-07-01 trunk 32356) [i686-linux]
0.7640390000000309

real    0m4.079s
user    0m2.872s
sys     0m1.192s


The performance degradation can be seen by not only such micro benckmarks,
but also my puzzle solvers :-(


There are some approaches to address the problem:

  1. to introduce a generational GC; this is impossible until 2.0 because
     it requires modifications to all extension libraries.

  2. to diet rubygems; do not create any string, array, hash, and any
     object as much as possible, and do not keep the references to them.

  3. to restore gem_prelude.rb to delay loading rubygems.

I guess that 3 is a reasonable choice for 1.9.3.  But I'm fine with any
solution to fix rubygems if 1.9.3 becomes as fast as 1.9.2 on the
benchmarks.

-- 
Yusuke Endoh <mame@tsg.ne.jp>


-- 
http://redmine.ruby-lang.org