However, require_relative still makes indirect calls to rb_feature_p.

On Sep 24, 2011, at 8:41 PM, Juan Wajnerman <jwajnerman / manas.com.ar> wrote=
:

> On Sep 24, 2011, at 8:19 PM, Intransition <transfire / gmail.com> wrote:
>
>>
>>
>> On Sep 24, 7:12 pm, Juan Wajnerman <jwajner... / manas.com.ar> wrote:
>>> I've been following the performance of Ruby 1.9.x since the beginning. =
I work with many quite big Rails projects and as the number of used gems ex=
plode, the impact on the loading time for the application has increased ver=
y noticeably.
>>> I know this is not new and also noticed the improvements on the 1.9.3-p=
review1 and head versions.
>>>
>>> Loading time maybe is not so important in production environments. Ruby=
 is not slow for most of our needs. But what is still a little bit annoying=
 for the development process is the time it takes to load a console or run =
a rake task.
>>> So I decided to figure out what is still making the start up quite slow=
.
>>>
>>> What I found so far is that a considerable time during loading is spent=
 in rb_get_expanded_load_path(). Also I figured out that for all the projec=
ts I tested so far, the result of this function is exactly the same as rb_g=
et_load_path(). That means, the paths in the load path are already expanded=
.
>>>
>>> So I changed the call in rb_feature_p and automatically obtained 10%~20=
% of improvement in the loading time for my projects, but I think it could =
be more for even bigger applications.
>>>
>>> Of course such change would break compatibility in case someone sets no=
n expanded paths, but I just want to note how important is to avoid expandi=
ng the same paths all the time. Maybe someone with better knowledge of the =
Ruby internals can come up with an idea of how to make a non breaking chang=
e to accomplish that. Again, I didn't find so far any broken project becaus=
e of this change.
>>
>> Not a direct address of the internals you speak of, but with 1.9 the
>> use of relative_require should greatly speed up load times as it
>> becomes more widely used.
>>
>>
>
> That's true! I've been testing that also and I've been making a script
> to help convert gems to use require_relative wherever possible. Not
> finished yet but obtained more improvements for some gems.
>