Mobile Orchard interview > further questions (garbage collection/performance)

Solar2D General Questions/Discussion
#1

Walter,

I found the Mobile Orchard interview interesting and of course, it leads to further questions. (-;

There was a brief discussion on garbage collection - the reuse of texture maps into OpenGL instances is great.

Are you considering any way to expliciting force memory dealloc in lua (specifically for media assets)? Incremental garbage collection might be ok for simpler things, but as an example, where we have to unload all assets for a level and load up new assets for a new one, I’m concerned that as we load image assets, the OS will send a low memory warning. I can envisage the garbage collector being too slow in it’s incremental cleanup and the OS will terminate the app before garbage collection happens.

Also - what happens with audio assets? Are they buffered into memory? Any ways of expliciting dealloc-ing those? I have a couple of potential projects that require many audio assets and I’m wondering how Corona would handle this use-case.

From my work with FlashLite, these have been two of the major problematic areas (memory usage for images and audio) of the Flash Player runtime - so naturally, I’m concerned here about Corona.

On the section on performance, the eventual aim of compiling to native ARM code sounds very positive. Is there any way we can profile our code running on Corona on the device?

Also looking forward to hearing more in due course about triggering the keyboard as mentioned in the interview.

Thanks,

  • Ian [import]uid: 238 topic_id: 96 reply_id: 300096[/import]
#2

Hi Ian,

Great question! We hit this problem — a low memory warning occurring and the GC not collecting in time — and do some things on your behalf to address this.

When your app encounters a low mem situation, the GC does a full collection to try and free up memory. However, it will only free up things that no longer have references to them (e.g. from globals or objects indirectly referred to by globals).

You can help the GC free up memory consumed by media assets:

* For event sounds, if you store a reference to the event sound (such as in a global variable or a table that will not be collected (e.g. a display object in the display hierarchy), nil out that reference.

* For long playing sounds, playing a new sound (e.g. mp3) implicitly frees the previous one since you can only have one such audio file active at once.

* For images, the memory consumed by the image is not freed until all display objects referencing that image are collected. So the key is to remove display objects from the hierarchy that you don’t need anymore. See “Removing Objects Properly” in the “Graphics and Drawing” Chapter of the AppProgrammingGuide.

Often, it’s convenient to place related objects in the group. That way, you can remove them all from the hierarchy by simply removing the group.

However, optimization is a funny thing. There are always tradeoffs you need to be aware of since mobile devices like the iPhone are resource constrained (battery, memory, cpu). One of these tradeoffs is the classic memory vs speed tradeoff: If you are too vigilant about removing objects and re-adding them later to keep the memory footprint low, then you can end up hurting the responsiveness of your app.

Though you won’t see this on the simulator, you will on the device where loading images incurs a double penalty (one from reading off the disk; another from “pre-flighting” the image into OpenGL). So the rule of thumb is to keep large images around (don’t remove them) if you’ll repeatedly use them during the app’s lifetime (e.g. a background for the home screen). The trick is to not have too many of those at once!

We’d like to make tracking memory consumption more transparent. Ideas include:
* Showing live memory consumption of the app in the simulator — perhaps breaking it down by asset type.
* Creating a “memoryWarning” system event that you can register for. This event would come prior to a full GC. This gives you the opportunity to nil-out references to media assets which would then get collected.

Let us know what ideas you have. And concrete examples from your Flash Lite days would be especially appreciated!

cheers,
Walter

[import]uid: 26 topic_id: 96 reply_id: 44[/import]

#3

@Walter

RE: We’d like to make tracking memory consumption more transparent. Ideas include:
* Showing live memory consumption of the app in the simulator — perhaps breaking it down by asset type.
* Creating a “memoryWarning” system event that you can register for. This event would come prior to a full GC. This gives you the opportunity to nil-out references to media assets which would then get collected.

Great idea!
I have run into a memory usage wall and could use these tools to try to find who the troublemaker is.
Keep up the good work.

  • Alan [import]uid: 6114 topic_id: 96 reply_id: 8081[/import]