Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Article on memory management #12

Open
jetpad opened this issue Nov 16, 2012 · 0 comments
Open

Article on memory management #12

jetpad opened this issue Nov 16, 2012 · 0 comments

Comments

@jetpad
Copy link

jetpad commented Nov 16, 2012

It would be great to have an in depth article on managing memory with RubyMotion. I don't know exactly what to ask for in the article because I don't know what I don't know.

One issue is that I discovered is that I wasn't using Xcode's instruments correctly. I was tracking the "simulator" process instead of my own app within the simulator. After that discovery, it makes instruments much more useful.

Another issue would be how to effectively use "autorelease_pool". I've found it doesn't hurt to put it in multiple places in the code, especially as the first thing inside loops. Another significant thing seems to be that it can be nested in the code. At first when I started using it, I was afraid to nest it but it seems to work fine that way. It doesn't solve all the memory release problems and I'm unsure of exactly what is happening when it doesn't work.

In past correspondence you've said "it is better to avoid creating too many objects in a single method". Maybe a little more into exactly what is happening in that case or how many is too many. If it is a lot, does it help to wrap sections of them in autorelease_pool? What exactly is the situation when RubyMotion isn't able to free up memory that isn't used anymore?

...and you said "I should try to defer that asynchronously (using the Dispatch module)"

I've had mixed success with that. I've broken up a long tasks into blocks that are put in an async queue but memory still doesn't seem to be freed up after each block finishes. Adding "autorelease_pool" around pieces of those blocks does help but why doesn't the memory allocated in those blocks already get freed when the queue block finishes? From using "instruments" it seems that the heap memory is getting freed after each queue block finishes but the overall memory still creeps higher and higher as more blocks are processed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant