On Thu, Dec 23, 2010 at 9:55 AM, Trans <transf...@gmail.com> wrote: > On Dec 23, 4:24 am, Charles Oliver Nutter <head...@headius.com> wrote: > The two I know of are gem-wedge and ore. > > Ore is especially ironic, b/c I was recently told that RubyGems did > not need to support plain YAML specs itself b/c a plugin, like Ore, > could do the job.
How does this break them? > Doesn't the file system itself cache the file access, so after the > first run it speeds up for every subsequent use? So it's not quite > that bad. But to be sure I am not against fixing this, I just don't > want to see non-command plugins broken to do it. Yes it does. With 500+ gems the uncached startup time on JRuby was 17 seconds. Cached time went down to 6.9. Without plugin scanning, under half a second. I consider that pretty bad, even cached. > A real solution would check for a plugins at install time, if one is > found copy it to a special location, e.g. gems/plugins, in much the > same way that a gem's specification is copied to a special location. > Then when Rubygems is loaded there is no need to search the file > system, all the plugins are in one place. Agreed. That doesn't seem like something that can land in the short term. This is a very clean, very light patch for a magnificent improvement, at the cost of a handful of plugins. And depending on how they break, the workaround could simply be to require 'gem_runner' (or to create a new "plugins.rb" with the plugin-loading logic, and then the workaround is to require that). - Charlie _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
