require needs to treat case-insensitive file paths in LOADED_FEATURES as case-insensitive for searching purposes

Preliminary fix pushed in 6394276.

Bumping remaining work to 1.7 to see if ruby-core does anything else special.

Ruby issue is here: http://redmine.ruby-lang.org/issues/show/4255

It is closed, even though there are outstanding issues/questions about mixed filesystems.

The fix causes a 10%+ performance hit in startup time for a stock Rails app.

1.6.1:

$ time ruby -S rake environment
(in /Users/jfire/Development/scratch)

real	0m4.457s
user	0m5.273s
sys	0m0.388s

After reverting 6394276:

$ time ../jruby/bin/jruby -S rake environment
(in /Users/jfire/Development/scratch)

real	0m3.863s
user	0m4.577s
sys	0m0.367s

Note:

$ rails c
Loading development environment (Rails 3.0.7)
>> $".length
=> 639

My real world app has 1104 loaded features. I suspect that if we could use a non-linear array search, it would help require performance a lot. Not sure if we can use an auxiliary data structure though because $" is not immutable.

So it looks like the iteration in LoadService.featureAlreadyLoaded winds up transcoding every string in the array in order to do case insensitive comparisons with Java String objects. Is there some way to avoid that overhead, say by indexing directly into the array rather than using an Iterator?

Just merged a3afa944 from John that he says improves this somewhat. Still need this to be open?

That commit reclaims most of the performance loss, but I think the bug was being kept open for other reasons.

I handled http://redmine.ruby-lang.org/issues/4255 and just have re-closed it as 'Rejected' (Heh, I don't like the word 'reject'.) CRuby 1.9 stores expanded path String in $LOADED_FEATURES. It's not a String specified by script but a String returned by a file system so there's no case-mixing issue as far as developers don't insert Strings to $LOADED_FEATURES by hand.

So for JRuby, I'm going to remove case-insensitivity feature for 1.9 and 1.8.

1.9 mode should be safe as I described above. If it's not safe, there's another bug around expand path or classpath handling I think.

For 1.8 mode, it might cause a problem for double loading but it's acceptable for users I think because CRuby 1.8.7 has the same issue.

  C:\Users\nahi\Documents\tools\ruby-1.8.7-p302-i386-mswin32\bin>ruby -v
  ruby 1.8.7 (2010-08-16 patchlevel 302) [i386-mswin32]
  
  C:\Users\nahi\Documents\tools\ruby-1.8.7-p302-i386-mswin32\bin>copy con foo.rb
  p :LOADED
  ^Z
  
  C:\Users\nahi\Documents\tools\ruby-1.8.7-p302-i386-mswin32\bin>ruby -I. -e "requ
  ire 'foo'; require 'Foo'; require 'FOO'; require 'foo.rb'; p $LOADED_FEATURES"
  :LOADED
  :LOADED
  :LOADED
  ["enumerator.so", "foo.rb", "Foo.rb", "FOO.rb"]

I'll update master branch first. How about jruby-1_6?

Committed to master. Sorry for writing the similar thing again and again.

commit 65c07ea2a5aa7827e415dd7f12ea475e17399bbf
Author: Hiroshi Nakamura <nahi@ruby-lang.org>
Date:   Mon May 23 12:44:17 2011 +0900

    JRUBY-5320: remove case-insensitive LOADED_FEATURES scanning
    
    6394276 introduced case-insensitive LOADED_FEATURES search on case-insensitive
    File System; Windows and Mac OS X. But in 1.9 (in both JRuby and CRuby),
    LOADED_FEATURES stores expanded path so it should not be a problem as far as
    we compare expanded path with LOADED_FEATURES. After merging require_protection
    branch, master branch should handle expanded path correctly now.
    So I revert the case-insensitive FS feature.
    
    It still be problematic in 1.8 mode but CRuby 1.8 has the same issue. 1.8
    users should aware of this problem.
    
    NB: JRuby has extended feature loading for *.jar and *.class so it might cause
    a problem for these extensions. I don't find any problem at present though.

Closing. The fix is in 1.7.0. I don't think whole require fixes at master is suitable for stable branch.