You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: