Musings of a Trained Monkey

Unspace.ca has released some interesting code to the open source community this year. September 13th, 2006 has them unleashing the first Rails plugin code that will make you want to gouge out your own eyes upon viewing the example code.

"The Agony" in the title of this post relates to the release of the HAML plugin. (Somewhat irresponsibly linked to by me, seriously please don't gouge out your eyes) Why, oh why, did they decide to combine white space sensitivity with HTML? Is there a disgruntled postal worker/Python programmer working there or what? Perhaps it is used in some sort of hazing ritual for their new employees.

On the other hand we have "The Ecstasy", the very useful Datagrid. This is an excellent and worthy open source release. It combines functionality with a great example of use. Granted it would be nice if it was packaged as a Rails plugin, but back in March adding routes in a plugin would have been difficult.

Anyway, I am looking forward to see what Unspace.ca will do next, hopefully they will serve up more of "The Ecstasy"

Some loose ends will be tied up here soon. Here is a quick list of things that I intend to post more about soon. Suggestions/requests will be taken from comments as well :-)

• AJAX-ed OpenRico Accordion widget
• $LOAD_PATH and Revealing some Rails Magic Tricks
• Edge Typo's New Pluggable Sidebars
• Installing RubyGems on TextDrive Done!
• Further Exploring the Limits on TextDrive:
• [rhesus@davie ~]$ ulimit -a
  core file size (blocks, -c) 0
  data seg size (kbytes, -d) 40960
  file size (blocks, -f) unlimited
  max locked memory (kbytes, -l) 32768
  max memory size (kbytes, -m) 49152
  open files (-n) 240
  pipe size (512 bytes, -p) 1
  stack size (kbytes, -s) 16384
  cpu time (seconds, -t) 1200
  max user processes (-u) 20
  virtual memory (kbytes, -v) 81920
  

I did gain some insight into the number of Gem::GemPathSearcher instances through my efforts. They correspond nicely for each piece of Rails that is loaded; ActionMailer, ActiveSupport, ActiveRecord, ActionPack, ActionWebService and Railties. Each of these has the require 'rubygems' statement in it. I believe this is why I was seeing multiple instances of Gem::GemPathSearcher.

As explained before instances of these take up an amount of memory proportional to the number of gems/gem versions in a repository. Making Gem::GemPathSearcher a Singleton of course, resolves more than one instance being loaded into memory. This has been submitted as a patch to RubyGems [ticket #5394].

Installing a patched version of RubyGems 0.9.0 on TextDrive to demonstrate the fix with Typo proved to be the most frustrating part. I will write a follow up posting on exactly how to do this in the near future. Hopefully they will release an updated RubyGems soon!

Shared hosts will definitely want to patch their RubyGems installs to reduce their memory consumption across all of their Rails users. TextDrive in particular should buy me a present or something :-)

I've learned a great deal about the Ruby memory ecosystem by digging into this issue with RubyGems. I got help from some folks on the Rails mailing list but far and away I want to thank Stef Telford for the help. Mad props to you for putting up with all of my questions and ramblings!

Finally some numbers:
Gem::Dependency x330(57415)
Gem::Version::Requirement x693(61939)
Gem::SourceIndex x1(1632488)
Gem::GemPathSearcher2 x1(1647806) <-- Gem::GemPathSearcher x5(7901012)
Hash x1219(1789928)
Gem::Specification x362(1795089)
String x113992(3876455)
Array x7415(5080185)
TOTAL == 16967273                          <-- TOTAL == 28496875

Update: These memory numbers are lower than actual process size. They vary by number of Modules loaded as well as Objects counts. Not all Objects and Modules can be evaluated for memory size. The new routing code in the latest version of Rails may also account for some of the difference as well. So grain of salt...