addChild:image uses alot of memory

xidadesign

Hi,

when you do the following (with a big image png/jpg) the memory usage grows fast:
image = [[[SPImage alloc] init] autorelease];
image.texture = [SPTexture textureWithContentsOfFile:cPath];
[self addChild:image];
The thing is, that the memory grows on the last line, when you add the child.
However, when you remove the child, the memory does not come back.

Also the used memory seems alot.
Say you add a image 391px x 554px.
The memory usage grows by 10MB.
Is that normal?

Shilo

Hello guys, and Daniel 😉

As my friend described above. We are trying to optimize our memory usage with an iPad project, using PVR images and deallocing unused objects and so forth. But we recently noticed that we could possibly save on memory if we retain the images, but add them to the stage when needed, and then remove them from stage when out of view while still retaining the image.

So once we alloc/init the image and retain it, it uses up some memory, but as xidadesign said, once we add it to the stage, the memory usage jumps higher then when the image is just allocated.

I have created a demo project to demonstrate the issue here: http://cl.ly/95Z6

It is a universal app which allocs and retains a decent size image on load. There is a textfield which displays the memory usage and memory free data on the top left corner. At the bottom it has 4 buttons which will add/remove the image, the buttons include:
"Instantly Add/Remove" - Will instantly add and remove the image onto the stage.
"Release/Alloc Image" - Will release then realloc the image to salvage back the memory used.
"Add/Remove Delay" - Will add the image to the stage, then release it after a 5 second delay.
"Add/Remove After Added" - Will add the image to the stage, then release it once it has dispatched SP_EVENT_TYPE_ADDED_TO_STAGE.

The only process that seems to use up memory is removing the image after a delay ("Add/Remove Delay"). If you mess around with the buttons and realloc the image, you will notice the same effect.

I know the best way to salvage back memory would be to completely release the image and save the image path into an NSString. But some of our code deals with downloading images and there is quite a lot of images on the stage. This just seems like a solution that could be a shortcut if we can get it working. Any ideas?

Daniel

Hi guys!

Hm ... that sounds really odd!

I had a look at it -- thanks for creating the demo project! That makes it much easier for me to test! 🙂

I cross-checked your findings, and the output of your memory-info-functions, with Instruments. For this, I used the blank instruments template and added the "memory monitor" tool. Then I had a look at the "samples", so that they are displayed one after the other (in time).

The interesting column are "physical memory used" and "physical memory free". On my 3GS, the game starts with roughly 100 MB used / 20 MB free.

And it stays that way, whatever I touch, and also during the 5 seconds the image is displayed.

So you might be after a red herring here!

When you add an object to the stage, it is added to an NSArray, and two events are dispatched ("added", "added_to_stage"). That's it! So I have no idea why it should suddenly use more memory.

I guess the problem is that the memory-info functions you are using are not accurate, or do not work as they should on the iOS.

But perhaps you can try it yourself with Instruments! Personally, I trust those tools more, since they are built especially for Objective-C, and I guess that Apple uses those itself to profile their applications and libraries.

Shilo

Well I know the simulator shows really inaccurate memory compared to the device. I tested the in-app memory displays with Activity Monitor instrument, and Memory Used is actually on par with the Activity Monitor instrument's "Real Mem" column.

When adding the image with a delay, it shows increased "Real Mem" until I reallocate the image. So i'm still stumped. But who knows! I went with dynamically loading/unloading the textures on a background thread anyhow.

Daniel

Hm ... very odd. Please keep me updated if you find out anything else, or if there's something else I should try!

Shilo

Lets bring up an old topic!

The memory issue is still very much a problem.

Let me explain a little of what we are developing:
An iPad app that displays an array of SPImages on stage in sequence to simulate a 3d rotating model effect. We pre-load the image textures in the background, than instantly add the images to the stage while only having one image (frame) visible at a time. The end-user is able to drag around the stage to seemingly rotate the virtual 3d model (which just toggles visibility on all the images to only allow the current image/frame to be visible).

The problem with this is the client is running into low memory which ends up crashing the device. I have confirmed that it is NOT a memory leak, and instead, due to memory increasing when rendering an image. The "extra" memory is NOT released after the image is invisible or released from the stage. The "extra" memory is only released after releasing the image.

I say "extra" memory because: Memory seems to be used on initializing the image/texture. Than more memory is used when rendering the image on stage. I assume OpenGL ES or the graphics card caches texture data once it has been rendered.

What we would LIKE to do is: Toggle the visibility of the image to NO or remove the image from stage AND release that "extra" memory that is being used during rendering of the image/texture.

I confirmed that SPTextureCache is not the cause of this. I dug into SPGLTexture and found out that the following call will successfully release that "extra" memory:

glDeleteTextures(1, &_name);

I was thinking, a good trick might be to manually call glDeleteTextures() and re-generate the texture. I assume this would release the cached "extra" memory, while still keeping SPGLTexture uncorrupted. Of course, this is really tough with the current setup of SPGLTexture, so I had little luck implementing it.

Now lets get to a sample project of this memory issue!
ImageMemoryText: http://cl.ly/VhdV

This sample project will show the statistics such as: fps, draw count, memory free, and memory used.

It also presents 4 buttons on the top:

You can also change the behavior of the app by toggling the following define:

#define TOGGLE_VISIBLE_INSTEAD_OF_ADD_REMOVE NO

When "TOGGLE_VISIBLE_INSTEAD_OF_ADD_REMOVE" is set to YES, it will change the displayed button texts to the following:

When initializing the image, it will use some memory. After adding the image to stage and/or setting the visibility to YES, it will use MORE memory. This is why I assume it uses memory on render. When removing the image from the stage and/or setting the visibility to NO, it will NOT release any memory. I expect it to release the memory that was used during render, or I would like an option to choose to release the memory. The only way it removes the "rendered-based" memory is when you dealloc the entire texture/image.

Now you might still wonder if the on-screen display of memory is accurate. I did a quick test with Instruments, and here is the graph:

You can see that the allocations released are only at the very end, when I release the image.

Thank you in advance!

Daniel

Thanks a lot for the detailed description and sample project!
To all readers, this is a perfect example for a bug report. Follow Shilo's lead, please! 😃

As for the sample, I can reproduce that in the simulator — it acts just as you describe it. However, on an actual iPhone (4S, iOS 7.1), that does not happen. The image takes up all the memory when it is added / the memory does not change when I click on "show image". Then, when removing the image, the memory is released.

So could that be a simulator problem? Did you try on a device, as well?

Shilo

Thank you Daniel!
To all readers, this is a perfect example of testing correctly. Follow Daniel's lead! 😉
Device > Simulator.

Seriously though, I tend to use Simulator much more often than Device because it is so much more convenient. When I build for a device, I often run into profile and entitlement errors. If it builds without errors on the device, I still have to constantly stand up to interact with the device after each build. Also, the apps usually require pre-downloaded content/data.

So frankly, I must not have tested BOTH of those samples projects, nor the actual project on the device. After testing the sample project on the device, there is no weird memory issues.

Thank you for testing and I apologize for wasting your time. 😉

CASE CLOSED.

Daniel

No problem, Shilo! I totally see what you mean — testing on a simulator is much more convenient, and 90% of the time, it's just fine.

I'm just happy to hear the problem solved itself, then! 😃
And your reports lead to some other leaks being fixed on my side, so it was not in vain. 😉