Thanks for your information on process size functionality.
Actually the process size does get smaller -- it changes size by about 17% on alternating requests when the AR collection of 10,000 objects is being rendered -- so a process can shrink -- but I don't know why.
I'd like to know more about what it would take to change the functionality of how a process works so that it was able to shrink in response to further requests which didn't uses as much memory. While this may be functionality that is not part of core Rails someone on this list might be able to point me towards work others are doing in this area.
The problem I am investigating is an app that uses much more memory when I create a instance variable with a collection of AR objects in the controller and use that in the view than if I do not create that instance variable in the controller and instead just create the AR collection in the view.
This may be due to a bug in rails but I need to continue to develop a simple test case so our information is useful for me to be able to progress towards either finding a bug in Rails or in my app. I wasn't planning on sharing more details about this issue with this list until I had determined it was a bug in rails. I did however think it was useful to describe the tests and instrumentation process I was using. I assume that folks on this list may have similar or more involved instrumentation strategies.
I think it is useful to report to the core list that the leak Ara wasn't able to track down last October is still present and to document the test that shows this result.
I'm curious about why instantiating an AR model object takes approximately 15x the size of the object when stored in the db and think this is also a question best directed to the core mailing list.
Does anybody have suggestions about better venues for raising these questions?