On Sep 24, 7:12 ¨Βν¬ Κυαξ ΧακξεςναΌκχακξες®®®ΐναξασ®γον®αςχςοτεΊ
> 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 explode, 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-preview1 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 projectsested 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 beore 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 expandinghe 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 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.