[ruby-core:38342] [Ruby 1.9 - Feature #5056] About 1.9 EOL

Issue #5056 has been updated by Jon Forums.


I would like to see 2.0 clean up performance regressions on Windows introduced by 1.9. Cleaning up the Windows performance regressions is important for 2.0 and for removing a key roadblock for Windows users transitioning from 1.8 to MRI 1.9 or 2.0.

While work is ongoing to address `require` performance issues, I'm not aware of anything being done in the Windows IO area. This post is a summary of what I've found on file read performance between different MRI versions and JRuby. I'll include Rubinius once I get it to build on Win7.

I've created a rudimentary benchmarking/tracing/profiling helper tool at https://github.com/jonforums/measurements and the micro-benchmark results (disk based, not RAMdisk) are generated by two of the core workloads. Given the nature of micro-benchmarks, the helper tool really needs independent review to see if it's giving bogus results[1]

With those caveats, here are my current raw results https://gist.github.com/1097249  All MRI Rubies were built on Win7 32bit with the MinGW-based RubyInstaller recipes, and JRuby is their plain vanilla download.

Two interesting results:

1) For binary file reads (CRLF or LF), MRI 1.9.x outperforms both MRI 1.8.7 and JRuby 1.6.3 in 1.8.7 mode. Nice work!
2) For non-binary file reads (CRLF or LF), MRI 1.9.x is *dramatically* slower than both MRI 1.8.7 and JRuby 1.6.3 in 1.8.7. Below are the results. When it takes 1.9.2-p290 20.15s (real time) to do what MRI 1.8.7 does in 2.56s and JRuby 1.6.3 does in 3.62s, something is fundamentally wrong. Particularly if normal usage by libraries and user code opens files for reading in 'r' rather than 'rb' mode. The same problem persists in MRI 1.9.4dev.


## microbenchmark for normal reading of file with CRLF endings

C:\projects\measurements-git>pik run rci bench core_rd_filelines_crlf

jruby 1.6.3 (ruby-1.8.7-p330) (2011-07-07 965162f) (Java HotSpot(TM) Client VM 1.6.0_26) [Windows 7-x86-java]
Rehearsal ----------------------------------------------------------
core_rd_filelines_crlf 3.853000 0.000000 3.853000 ( 3.826000)
------------------------------------------------- total: 3.853000sec

                             user system total real
core_rd_filelines_crlf 3.629000 0.000000 3.629000 ( 3.628000)


ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mingw32]
Rehearsal ----------------------------------------------------------
core_rd_filelines_crlf 1.856000 0.156000 2.012000 ( 2.146123)
------------------------------------------------- total: 2.012000sec

                             user system total real
core_rd_filelines_crlf 1.779000 0.281000 2.060000 ( 2.560147)


ruby 1.9.2p290 (2011-07-09 revision 32478) [i386-mingw32]
Rehearsal ----------------------------------------------------------
core_rd_filelines_crlf 19.781000 0.187000 19.968000 ( 20.216156)
------------------------------------------------ total: 19.968000sec

                             user system total real
core_rd_filelines_crlf 19.672000 0.156000 19.828000 ( 20.153152)


ruby 1.9.4dev (2011-07-21 trunk 32590) [i386-mingw32]
Rehearsal ----------------------------------------------------------
core_rd_filelines_crlf 18.236000 0.094000 18.330000 ( 18.392052)
------------------------------------------------ total: 18.330000sec

                             user system total real
core_rd_filelines_crlf 17.675000 0.078000 17.753000 ( 17.846020)  


I'm publishing this info much earlier than I normally would because (a) it needs more eyes reviewing for validity, and (b) I don't want the issue to appear too late in the 2.0 development cycle to resolve.  I'd be more than happy if it turned out that "there's no performance regression, you're just doing it wrong!"  While I dislike eating steaming plates of crow, I hate that MRI Ruby runs fundamentally slower on my Windows boxes than on my Arch and Ubuntu Server boxes.

I'm going to continue investigating, but sadly I'm not able to give it as much time as it needs to resolve due to real, paying work. I'm hoping the issue is interesting and challenging enough so that (a) it can attract others, and (b) MRI project leadership views the issue as important for MRI's success and resources appropriately.

Thanks for your review and consideration,
Jon

[1] https://github.com/jonforums/measurements/blob/master/lib/inquisitor.rb#L57-103
    https://github.com/jonforums/measurements/blob/master/workloads/core_rd_filelines_crlf.rb
    https://github.com/jonforums/measurements/blob/master/workloads/core_rd_filelines_lf.rb
    https://github.com/jonforums/measurements/blob/master/workloads/core_brd_filelines_crlf.rb
    https://github.com/jonforums/measurements/blob/master/workloads/core_brd_filelines_lf.rb
----------------------------------------
Feature #5056: About 1.9 EOL
http://redmine.ruby-lang.org/issues/5056

Author: Shyouhei Urabe
Status: Assigned
Priority: Normal
Assignee: Yukihiro Matsumoto
Category: Project
Target version: 2.0


=begin

At RubyKaigi,  I was surprised to  hear Matz saying "there  will be no
1.9.4 because it becomes 2.0".

Question 1: are you kidding?  or seriously speaking?

Question 2:  do you have  plan(s) for making  1.9 branch just  like we
have  1.8 branch  now?  or  the  whole 1.9  series just  die when  2.0
development starts?

Question 3: who take care of the 2.0 branch? and who for 1.9 (if any)?
Currently yugui  is the mentor of  1.9 series.  Does she  shift to 2.0
mentor and new 1.9 person to appear, or she remains to 1.9 and new one
for 2.0?

=end



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