0

I was wondering if there is a rule of thumb to estimate the raugh runtime memory usage.

That's my current "mental algorithm":

  • sprite frame sheets: e.g. 2048*2048= approx 4MB runtime (I have 1 sheet for HUD and Input sprites, 1 for player characters and bullets, 1 for enemies, 1 for background for a total of 16 MB)
  • mp3 background track: size of track, e.g. 4 MB for a 192kbps 3 minutes song Does this actually expand into caf and become bigger?
  • caf files: size of caf file (I have about 15 caf files of about 300KB each so sum would be 4.5 MB)
  • I tend to ignore the number of CCSprite subclasses that I allocate but for instance I could multiply each sprite for the average size of my CCSprite subclasses (e.g. .m file 45 KB = 41.270 byte and .h file 4KB for a total of 49KB avarage): if I use BulletCache with 200 bullets and an EnemyCache with 50
    sprite plus approximately 100 other CCSprite subclasses (HUD,
    buttons, player sprites) the simplified sum could be 350. So we have 350 * 49KB = 17.150 KB which is raughly 17 MB.

So a total of 17 + 4.5 + 16 + 4 = 41.5 MB runtime memory usage

Would this be a reasonable enough way to estimate?

mm24
  • 9,280
  • 12
  • 75
  • 170
  • 1
    Would this be useful? http://stackoverflow.com/questions/5012886/knowing-available-ram-on-an-ios-device – James Mar 05 '13 at 18:50
  • @James It is useful so thanks, but was wondering if the reasoning behind was correct or if there are some other major things that I was missing.. – mm24 Mar 05 '13 at 20:11

1 Answers1

1

I wrote an article about calculating / estimating the size of in-memory resources.

You make a couple assumptions, some of them are wrong. Allow me to point them out:

A 2048x2048 with 32-Bit color uses exactly 4 MB. At 16-Bit color depth it would be half that. You can trim even more memory if you make the texture NPOT (recommended) and by using .pvr.ccz as file format (also recommended).

MP3 are not normally loaded in their entirety in memory. MP3 is a streaming format. Played properly, only a small amount of memory buffer is needed to stream (play) the MP3.

You can not estimate the size of class instances by looking at the file size of .h/.m files. That is completely wrong because you're comparing Apples (source code, text) with Oranges (class objects, binary). But you're right that the size of class instances can be neglected in almost all cases. Most cocos2d node class instances use less than 512 Bytes - just counting the memory needed for the class' ivars. You can check the size of class instances yourself with class_getInstanceSize.

Finally, these kinds of estimations are only useful when you have an idea for a project or feature for an app and you need to estimate the resource usage just to make sure you're not going to allocate gigabytes of memory. In all other cases monitor the actual memory usage of the app with Instruments.

CodeSmile
  • 64,284
  • 20
  • 132
  • 217