Yup, it will do, ruby doesn't give any memory it's allocated back to
the system. Try creating a bunch more objects - the process size won't
grow until the new objects are taking up more space than the old ones
because ruby will simply reuse the memory it's already allocated.
Getting memory from the OS is expensive, ruby (and perl and python and
almost every other interpreted language you can think of) assume that,
because the program gets that big once, it's likely to get that big
again, so it's a good idea to keep the memory hanging around ready for
that eventuality.
This probably isn't suitable subject matter for rubyonrails-core though. Ho hum.
Piers,
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?
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 don't know if these two are related, ara's leak was related to
session handling wasn't it?
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.
The fact that it uses more memory than the database uses on disk
shouldn't really come as a surprise. As far as the specific multiple
it could almost certainly be improved with some judicious memory
profling. Alexander Dymo's work has yielded some good payoffs lately,
if you're looking for tooling suggestions he's the guy to listen to:
http://blog.pluron.com/2008/02/memory-profilin.html
Does anybody have suggestions about better venues for raising these questions?
This is the best venue to discuss this stuff, at least unless the bug
is tracked down and shown to be some other problem 