[#28687] [Bug #2973] rb_bug - Segmentation fault - error.c:213 — rudolf gavlas <redmine@...>

Bug #2973: rb_bug - Segmentation fault - error.c:213

10 messages 2010/03/16

[#28735] [Bug #2982] Ruby tries to link with both openssl and readline — Lucas Nussbaum <redmine@...>

Bug #2982: Ruby tries to link with both openssl and readline

16 messages 2010/03/18

[#28736] [Bug #2983] Ruby (GPLv2 only) tries to link to with readline (now GPLv3) — Lucas Nussbaum <redmine@...>

Bug #2983: Ruby (GPLv2 only) tries to link to with readline (now GPLv3)

10 messages 2010/03/18

[#28907] [Bug #3000] Open SSL Segfaults — Christian Höltje <redmine@...>

Bug #3000: Open SSL Segfaults

19 messages 2010/03/23

[#28924] [Bug #3005] Ruby core dump - [BUG] rb_sys_fail() - errno == 0 — Sebastian YEPES <redmine@...>

Bug #3005: Ruby core dump - [BUG] rb_sys_fail() - errno == 0

10 messages 2010/03/24

[#28954] [Feature #3010] slow require gems in ruby 1.9.1 — Miao Jiang <redmine@...>

Feature #3010: slow require gems in ruby 1.9.1

15 messages 2010/03/24

[#29179] [Bug #3071] Convert rubygems and rdoc to use psych — Aaron Patterson <redmine@...>

Bug #3071: Convert rubygems and rdoc to use psych

10 messages 2010/03/31

[ruby-core:28690] Re: Indentifying key MRI-on-Windows issues

From: Roger Pack <rogerdpack2@...>
Date: 2010-03-16 16:30:26 UTC
List: ruby-core #28690
> My key concern is http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-=
core/24968
>
> I'm not yet clear as to the root cause. For example, is this #ifdef "fixa=
ble" for Windows due to implementation specifics of MRI's IO, or is it a co=
nsequence of needing to handle Windows CRLF and not a weakness in the curre=
nt implementation?

The "first" cause is that realloc in msvcrt.dll is for some reason
*very slow* -- at least with msvcrt6

Combine that with the fact that the read buffer size on descriptors in
mingw (or possibly windows itself) defaults to a very small value, and
that ruby by default reads only that much and resizes strings to
become that size, and you have the problem.

I did some work on this:
http://redmine.ruby-lang.org/issues/show/2742
(hopefully somebody will look at my patches sometime).

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.

There is a smaller problem after that one, too.  If you're reading in
ascii mode (the default in windows), it does a full scale encoding
translation of incoming bytes before passing them back to you.  The
good news is that this is only like 50x slower than a normal read, so
might be bearable.  It could use some optimization, I haven't looked
at it much.  You can work around that one by doing something like

# instead of
a =3D File.read 'abc'
# do this
a =3D File.binread('abc').gsub!("\r\n", "\n")

which is many times faster (but loses encoding coolness, if you needed
that).  Ruby could be optimized a bit in that regard.

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.

HTH.

-rp

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

In This Thread