Issue #3924 has been updated by satoshi shiba.


Hi,

Yusuke ENDOH wrote:
> Hi,
> 
> 2011/6/23 Hiroshi Nakamura <nakahiro / gmail.com>:
>> Anyone can imagine a downside of this? It could not work as expected
>> if the result of rb_file_expand_path *changes* during require (adding
>> a new file during require should work.) Do we need to care such a
>> case?
> 
> 
> As far as I look the patch, paths that are once stored in cache
> will never be collected.  It may be considered as a kind of
> memory leaks.
> 
> I guess that it is not a problem in casual cases.  But I'm not sure
> if it is really OK.
> 

May I ask current status of this problem?
"rb_file_expand_path()" is still a bottleneck of "rb_require_safe()".
So, I'm interested in this problem.

If memory leak is a problem, how about collecting strings at the time of mark phase.
I made a patch which is based on Shyouhei's patch to resolve memory leak.
A patch( https://gist.github.com/1805919 ) collects cached strings at the time of mark phase.

----------------------------------------
Bug #3924: Performance bug (in require?)
https://bugs.ruby-lang.org/issues/3924

Author: Carsten Bormann
Status: Assigned
Priority: Normal
Assignee: Yuki Sonoda
Category: core
Target version: 2.0.0
ruby -v: -


=begin
 Running irb < /dev/null in 1.9.2 causes 3016 calls to lstat64.
 
 For instance, there is a sequence of 28 repetitions each of lstat calls to all 6 non-empty path prefixes of /opt/local/lib/ruby1.9/1.9.1/irb.rb -- a total of 170 lstats apparently just to load this file; another set of lstats then occurs later for another 18 (times 6) times.  Clearly, something is running amok in the calling sequence rb_require_safe -> realpath_rec -> lstat.
 
 Another example: Running a simple test with the baretest gem causes 17008 calls to lstat.  According to perftools.rb, 80 % of the 1.2 seconds of CPU is used in Kernel#gem_original_require (and another 12 in GC, some of which may be caused by this).
=end



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