Quite some time ago I wrote a blog post about the number of temporary
strings that are loaded when rubygems starts up. (The largest culprit
is the file list for the gems).
I've been trying to think how to overcome this for some time, without
breaking the gems api, but a slightly more lightweight idea came to me
today, which may be workable prior to an architecture change.
Add another field for 'non-runtime files', for covering docs,
examples, rakefiles, tests, etc.
This would enable gem authors to maintain the ability to scan the
gemspec for important files (often under lib/), but unimportant files
would be missed out.
Initial saving on a development machine (averaging what we use in the
office), would seem to be around 30-40% of the instanced objects in a
`ruby -rubygems -e ""`
On a related note, I was considering a more architectural changeset to
gems, which I was going to stab case in a more external 'mini-gems'
package (may be quite some time away).
The plan is to move to something that's glob supported (and a new
directory structure aside that).
In order to accomplish this but maintain compatibility I envisage a
Gem.source_index that binds data as late as possible. A useful api
however would be to Gem.source_files.glob(), which would both simplify
and abstract the necessary piece of work for many of the current
'plugin' architectures built on top of Gem.source_index discovery. The
hope being that this slowly opens up the floor to such architectural
modifications, hiding them behind an API.
Any / all input would be most welcome,
Kind regards,
James.
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
