On Dec 22, 10:46 pm, James Tucker <jftuc...@gmail.com> wrote: > On Dec 22, 2010, at 5:56 PM, Charles Oliver Nutter wrote: > > > On Wed, Dec 22, 2010 at 1:33 PM, Charles Oliver Nutter > > <head...@headius.com> wrote: > >> Here's my naïve change and the impact to perf with around 500 installed > >> gems: > > >>https://gist.github.com/751969 > > > I'm guessing there's also potential fixes for that scanning process, > > all the way up to caching lists plugins on install (i.e. eliminating > > future scans altogether), but this is a good quick fix for > > non-command-line rubygems use. > > +1 on this patch for now.
-1 _for now_. > - This will break 4 gem plugins, mostly minor and I've never seen them used > 'in the wild'. I have the list knocking around somewhere, I'll dig it up if > someone reminds me when I'm awake. I know of at least two gems it will break, and I suspect they are not your four. I thought RubyGems was supposed to be so *conservative* about changes, and here a change is just going to be pushed that breaks people's plugins for the sake of a speed up for those who have 500+ gems installed? Overlooking the fact that there other solutions to deal with large gem collections, like rvm's gemsets. Why wouldn't the prudent course of action be to actually fix this _correctly now_, rather than implement a "phase 1" change that will leave certain types of plugins out in the cold for who knows how long? If that's asking too much, then at the very least, make this patch a configurable option in the .gemrc file. Power users who aren't using any of the above mentioned plugins could then easily flip the switch to get the speed up. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
