On Sep 24, 7:12=A0pm, 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 expl=
ode, the impact on the loading time for the application has increased very =
noticeably.
> I know this is not new and also noticed the improvements on the 1.9.3-pre=
view1 and head versions.
>
> Loading time maybe is not so important in production environments. Ruby i=
s not slow for most of our needs. But what is still a little bit annoying f=
or 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 i=
n rb_get_expanded_load_path(). Also I figured out that for all the projects=
 I tested so far, the result of this function is exactly the same as rb_get=
_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 non =
expanded paths, but I just want to note how important is to avoid expanding=
 the same paths all the time. Maybe someone with better knowledge of the Ru=
by internals can come up with an idea of how to make a non breaking change =
to accomplish that. Again, I didn't find so far any broken project because =
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.