Current Sparrow Github Version - Memory Problem

xidadesign

Hi,
I noticed that I don't get back the memory whenever I create a new SPImage with a texture and later remove it.

To test this and make sure is not a problem with my app I used the scaffold project and changed Game.m like this:

- (void)setup{

    NSLog(@"used memory %d", [self usedMemoryInMB]);
    [self performSelector:@selector(addTestImage) withObject:nil afterDelay:5.0f];

}

- (void) addTestImage {
    NSLog(@"add image");
    SPImage *image = [SPImage imageWithContentsOfFile:@"background.jpg"];
    [Sparrow.stage addChild:image atIndex:0];
    NSLog(@"used memory %d", [self usedMemoryInMB]);

    [self performSelector:@selector(removeTestImage) withObject:nil afterDelay:5.0f];

}

- (void) removeTestImage {
    NSLog(@"remove image");
    [Sparrow.stage removeChildAtIndex:0];
    [self performSelector:@selector(checkMemory) withObject:nil afterDelay:5.0f];
}

- (void) checkMemory {
    NSLog(@"used memory %d", [self usedMemoryInMB]);
}

- (int) usedMemoryInMB {

	struct task_basic_info info;
	mach_msg_type_number_t size = sizeof(info);
	kern_return_t kerr = task_info(mach_task_self(),
								   TASK_BASIC_INFO,
								   (task_info_t)&info,
								   &size);
	if(kerr == KERN_SUCCESS) return ((float)info.resident_size/1048576.0f);
	else return 0;
}

The logs I get are:
used memory 10
add image
used memory 19
remove image
used memory 19

I used "Product - Profile - Leaks" too.
This also only shows an increase in memory usage, no decrease.

Is it just me or did anyone else notice that problem too?

My setup:
XCode 5.1 with iOS SDK 7.1
iPad Air with iOS 7.0

Daniel

I just had a look at this, and there are two reasons for the problem:

(1) Sparrow's new Texture Cache

I noticed frequently that developers would create several texture instances from the same file, instead of re-using one instance. To make sure that this is not a problem, Robert recently added a texture cache. When you do the following now:

SPTexture *textureA = [SPTexture textureWithContentsOfFile:@"texture.png"];
SPTexture *textureB = [SPTexture textureWithContentsOfFile:@"texture.png"];

then the file won't be loaded 2 times. In fact, both instances will point to the same texture instance.

Of course, this also means that a texture is not released right away any longer; instead, the texture will be released only when the system reports that it requires more memory.

The cache is implemented using "NSCache", which was built for exactly this reason; so don't worry, no Voodoo is going on here. 😉

However, personally, I want total control over the memory — as you do, probably, as you are an advanced user. In that case, you can deactivate this cache completely. Simply call this before you load any textures.

[SPTexture setCachingEnabled:NO];

This needs documentation, of course! I'll add that to the manual as soon as this version is officially released. Thanks for the reminder!

(2) However ...

Still, Sparrow did not release the texture in the sample you provided, which puzzled me.

It turned out that there was a "release" call missing for that special situation (a scene with only images that are all removed from the stage). Nothing critical — in a real world scenario, nothing would have happened. Still, it needed fixing! If you pull now, your sample should act just as expected, after turning off the texture cache.

Thanks a lot for the heads-up!

I hope that helps! 😃

xidadesign

Wow! Thanks for the quick reply!
I just wanted to add that in the old version the memory was never cleared, even if the "memory warning" arrived.

I will test the new version now.

xidadesign

I can confirm that [SPTexture setCachingEnabled:NO]; fixes the problem.

However if I leave the caching on, the app will crash sooner or later.
I got the memory usage as high as 400MB on the iPad Air.
Then the "Received memory warning." arrives and soon after the app crashes "Terminated due to Memory Error".

Daniel

Hm, that's not supposed to happen, dammit! 😉
Thanks for the report, then — I'll look into it!

xidadesign

Just in case you don't know:
The Simulator has an option to simulate the memory warning.
This way you can quickly check if the cleaning of the cache works.

Daniel

I played around with it today, and indeed: that approach just did not work right. NSCache did not quite work out. 🙁

I replaced the implementation with a new one that does not have any side effects. You can remove the line "[SPTexture setCachingEnabled:NO]" now. In fact, that method was removed, too, since the new approach does not have any downsides.

It works like this. When you load the same texture two times, as shown in my previous post:

SPTexture *textureA = [SPTexture textureWithContentsOfFile:@"texture.png"];
SPTexture *textureB = [SPTexture textureWithContentsOfFile:@"texture.png"];

Then "textureA" and "textureB" will point to the same object. BUT if you do the following, they won't:

SPTexture *textureA = [SPTexture textureWithContentsOfFile:@"texture.png"];
textureA = nil; // or [textureA release] without ARC

SPTexture *textureB = [SPTexture textureWithContentsOfFile:@"texture.png"];

Here, when "textureA" is disposed, it is removed from the cache, as well. So no texture is ever kept alive if it is not needed.

I hope that helps! Again, sorry for the troubles! We should have tested this better.

Shilo

Texture caching seems to be fixed. As always, thank you!

Daniel

Thanks for trying it out, Shilo! 🙂
And, again, sorry for any troubles the old implementation might have caused.