From: Charles Oliver Nutter <headius@...>
Date: 2010-03-18T14:51:57+09:00
Subject: [ruby-core:28728] Re: Indentifying key MRI-on-Windows issues

On Tue, Mar 16, 2010 at 10:30 AM, Roger Pack <rogerdpack2@gmail.com> wrote:
> Those patches speed up some reads by performing fewer realloc's, but
> aren't the "best" way. ��The best way, (on windows) would be to avoid
> realloc's if at all possible (or put them off until the very end).
> Then ruby would probably read pretty fast. ��Jruby probably doesn't use
> realloc this way, and probably doesn't have the same speed problem.

JRuby does whatever the JVM does, and I know they've spent as much
time optimizing the JVM for Windows as they have for just about any
platform.

> Jruby doesn't do any 1.9 encoding support (that I'm aware), so again
> probably doesn't exhibit this, at least won't until they add encoding
> support and you run it in 1.9 mode, then it might.

JRuby does do encoding support, though it's not complete yet. I think
we just recently added the binmode stuff, but I'm not sure if it's
100% correct yet. Is there a benchmark we could run to see if we're
suffering from the same issues?

>> Are *nix systems able to IO optimize for this case while Windows systems cannot? ��Is the reason this performance delta isn't seen in JRuby[1] is that the JVM's cross-platform IO handling always has to handle both cases and therefore can't fully optimize for one platform, i.e. - all pay the price?

JRuby doesn't actually use much of the JVM's builtin IO string/newline
handling, since the JVM does not provide a simple way to do both
buffered and unbuffered IO from the same stream (which we need for
Ruby's IO). Our IO subsystem is basically written to emulate how MRI
and libc do things, but entirely atop the JVM's NIO Channels, which
are roughly like direct file descriptors. So any line handling we do
we're doing ourselves, in Java.

- Charlie