RubyGems and Memory, again...
I’ve been toying with switching over to Mephisto and spending some extra time studying memory consumption, which is quite a bit higher in Mephisto than Typo. Using the latest svn trunk of RubyGems (r1100), the bug with multiple Gem::GemPathSearcher instances being created has been fixed, but now there is a different problem. Multiple Gem::SourceIndex instances are created. I can see where this might be needed with the recent “incremental updates to the gem list” change that went into RubyGems, it doesn’t make sense to have these hanging around in memory for the lifetime of a Rails application.
I took the same approach to a fix as last time, adding the require and include for Singleton into the SourceIndex.rb class. This worked fine for loading up Mephisto and indeed reduced the memory use substantially.
| r1100 without Singleton | – Gem::SourceIndex x2(1062363) |
| r1100 with Singleton | – Gem::SourceIndex x1(97621) |
I haven’t checked to see how this change impairs RubyGems for getting new gems, update, etc. but it seems like there needs to be a different amount of information loaded for bootstrapping the gem command, versus a running Ruby or Ruby on Rails application.
- Does the running application really have a need to know the complete dependency hierarchy for all of the installed gems on a system?
- Even if your application did, would you want that information stored into memory from startup to shutdown?
UPDATE: Applying this change will indeed hamper RubyGems ability to install/update gems. I am now wondering how hard it would be to break Rails’s dependency on RubyGems altogether…