Sparrow Forum

1. 

   skywise
   Member

   Hey all!

   I'm currently trying to optimize my app; there are some requests about crashing on old devices and i knew that the app is sometime using a lot of memory.

   So, i'm checking for leaks, optimizing pictures and building atlases where there were none yet. So far, so good. But now, i'm coming up with a few questions i'm stucked:

   - I went to some functions with moving a return statement on different places (to find the points and amount the memory usage grows) and discovered the following behavior i don't understand:
   -> I alloc an image that is coming from an atlas which has been alloced a long time before. Theres almost no memory increase when creating the SPImage. Two lines later, i would like to add this image to my Sprite; guess what: my memory usage (instruments, on iPhone 4s-Device) is increasing by 16.02 MB !! Just by calling "addChild". My Atlas-Picture takes around 7 MB on disk, and the texture I'm taking of it has 377x377px.
   Whats going on here?

    
           NSString *myPicFile = [NSString stringWithFormat:@"tp_%@", myActualSetting];
           settedImage = [SPImage imageWithTexture:[atlas textureByName:myPicFile]];
           // Increases Memory by 0.3 MB
    
           [self addChild:settedImage];
           // increases memory by 16.2 MB !!!

   - And generally: Does an atlas save a lot of memory? After some changes, it doesn't seems so, it's just running significant faster and smoother, but memory-usage hasn't a big change ... ?

   Thanks for your advices!

   PS: I found an old thread about same issue, but there isn't an helpful answer at all:
   http://forum.sparrow-framework.org/topic/addchildimage-uses-alot-of-memory

   Posted 4 months ago #
2. 

   nilaf
   Moderator

   i donno about the inaccurate instrument reading . Just try with simulator. Still the sparrow experts working on it.

   About the texture atlas.Atlas takes less memory then all the individual image size added.N most important performance.iphone graphic device can handle one graphic at a time. so atlas saves this unnecessary swapping.If you want to further improve using pvr.gz ( quality compromised )

   Posted 4 months ago #
3. 

   skywise
   Member

   Thanks for your answer.

   instruments is the only way to get informations about the real System, CPU and Memory-Usage on devices. So, all customers use the app on devices, simulator won't be really usefull. It's great to check funcionality, but it doesn't care about System-Usage...

   All crashes appear, because my app is sometimes consuming up to 70MB of memory, just for a few seconds. But on the 3GS and the ipad, thats too much and the app crashes.

   Posted 4 months ago #
4. 

   borrrden
   Moderator

   The performance boost of Texture Atlases come in their use of texture memory in the GPU, which I don't think is measured by Instruments (though I could be wrong...). As nilaf said, OpenGL ES is only capable of storing one texture in GPU memory at a time (I think recent developments raised this limit to 2, but I'm not sure). When you want to use a different texture, it must purge that memory and fill it again with the new texture. Furthermore, for binary mathematical and performance reasons, OpenGL only accepts textures with sides that are powers of two. Sparrow handles this limitation for you by padding your texture to the next highest power of 2, so you will be wasting memory using any other size than a power of two.

   As for the memory usage, that stumps me as well. I see no place where it would possibly be accidentally reallocated.

   Posted 4 months ago #
5. 

   skywise
   Member

   Thanks for your thoughts, borrden!

   So, I did a lot of investigation on my memory and system usage and found out a few fact that seem strange to me ... But most important was to figure it out.

   - Yes, an Atlas instead of an single image-file speeds up everything - it's running far more smooth and quick. Noticable on all devices, but specially the old ones.
   - No, an atlas doesn't reduce memory usage by a big amount. At least when adding the selected texture to the stage. It takes almost same amount as the single file variant.
   - I achieved to save memory anyway by creating a lot of small atlasses and loading them inside the classes that need the files. Retaining a class-var and release it in dealloc seems to work perfectly.
   - Strange story: I played around with a lot of variants, creating big and small atlasses. it doesn't even matter how big the images inside are or how many pictures the atlas contains. BUT: funny thing, an 2048x2048px Atlas uses a lot less memory tham the same content in an atlas with 1024x2048px.I'm using texturepacker and learned to avoid the autosize-feature...

   Conclusion: When using atlases, make them always quadratic, even if half of the file will be empty. Strang ething, but saving a lot of memory.
   Also, the export-mechanism of a image matters a lot - even if the filesize is around 20% of another one, the small file on disk could take up more memory! Didn't find a rule yet, but playing around with a lot of graphic-tools (fireworks, photoshop, gimp, bridge, lightroom, and more) showed up with extremly different memoryusages ...

   Maybe this could be helpfull for some guys hunting for memory :-/)

   Ps: the problem in the first post persists: memory growing is showing up when adding to stage, not when allocating it.

   Posted 4 months ago #
6. 

   zyzzyxx
   Member

   I want to second this issue as well. I also see problem in first generation iPads.

   The memory usage increases when an object is added to the stage.

   I do release it as soon as I'm done with the object, but the Instruments shows that it takes a little bit of time to release the memory.

   This becomes problematic in the first Gen iPads, where the total RAM is 256 MB and if the objects are created and destroyed at a faster pace, soon iOS throws the memory warning.
   At that time, if you wait for couple of seconds, the memory release catches up and everything is good.

   What I fail to understand is: is this a Sparrow only problem? or is it a problem in iOS in general?

   Posted 2 months ago #
7. 

   TTStu
   Member

   release statements are not an instruction "dealloc this NOW" they are merely a hint "get rid of this when you can, device, 'cos I'm finished with it"... ie, there is no guarantee when this will happen.

   I perhaps suggest moving to ARC since it is much more efficient (in my limited tests anyways) of deallocing stuff as soon as they are de-referenced.

   Posted 2 months ago #

RSS feed for this topic

Reply

You must log in to post.