• [AS3/Starling] Take a lot of memory

Hi Nate,

I'm currently working on a project that use a lot of SpineAnimation - I have profiling my game using Adobe Scout and it seems thats Spine takes a lot of CPU usage and memory.

I have shared my Adobe Scoot report with Daniel, the author of Starling, he agreed that it's strange that Skin.getAttachment takes that much CPU.

I have to say that he had no access to my project, so his answer it just base on the Adobe Scoot report.

Maybe you have time to take a look at the Adobe Scoot report and tell me what you think. Maybe it's not Spine fault but the way I use it.

Thank you

Adobe Scoot report : http://we.tl/bhv05KbQms

Daniel's answer :

Hello Bali,

mhm, I just looked at the updated data, and I share your view: it's really odd that Spine takes up so much CPU time. When you look at this:

http://i.imgur.com/cKeeZDM.png

You see that "SkeletonSprite.render" takes a great share of the "self time" compared to other methods.

The second problem, even more severe:

http://i.imgur.com/rT4qHSc.png

You see that there are a lot of Strings allocated by Skin.getAttachment. This is responsible for the big orange bottom part of your charts: the GC has to do a lot of cleaning-up.

I'd try two things: first, to see what would be the maximum FPS you could reach, remove those objects temporarily or (better) replace them with static images. Then you see the upper bounds of the potential you have here. Then, if that makes enough of a difference (I guess it does), perhaps you can look into that method yourself and try to find if there's something done that might be the reason for the high CPU time.

[bali33 note : if I remove my game spine animations the FPS reaches 60 FPS - no problem]

Some easy things to fix:

  • avoid any temporary objects to reduce GC load. In many cases, you can create a few static objects in a class and reuse them, instead of creating new objects repeatedly. Look at the Starling code to see samples for this (search for "helper object").

  • avoid "array/vector.push()"

replace with "array[array.length-1] = ...";

  • if there's an array/list access with a math operation, like this: "list[i+2]" add an int-cast like this: "list[int(i+2)]".

  • if there's a "for" loop, be sure to exchange:

for (var i:int=0; i<list.length; ++i)
with

var length:int = list.length;
for (var i:int=0; i<length; ++i)
Those are small things that sum up. These changes could be made without understanding much of the internal Spine logic. Just be sure to start with those methods Scout tells you are most important; and especially "Skin.getAttachment" to avoid all those temporary Strings.

Good luck!!!
Please keep me updated about your progress! :-)

Cheers,
Daniel

Related Discussions
...

Can you start a forum thread so we can discuss this?

Thanks!
-Nate

bali33 wrote

Hi Nate,

I'm currently working on a project that use a lot of SpineAnimation - I have profiling my game using Adobe Scout and it seems thats Spine takes a lot of CPU usage and memory.

I have shared my Adobe Scoot report with Daniel, the author of Starling, he agreed that it's strange that Skin.getAttachment takes that much CPU.

I have to say that he had no access to my project, so his answer it just base on the Adobe Scoot report.

Maybe you have time to take a look at the Adobe Scoot report and tell me what you think. Maybe it's not Spine fault but the way I use it.

Thank you

Adobe Scoot report : http://we.tl/bhv05KbQms

Daniel's answer :

Hello Bali,

mhm, I just looked at the updated data, and I share your view: it's really odd that Spine takes up so much CPU time. When you look at this:

http://i.imgur.com/cKeeZDM.png

You see that "SkeletonSprite.render" takes a great share of the "self time" compared to other methods.

The second problem, even more severe:

http://i.imgur.com/rT4qHSc.png

You see that there are a lot of Strings allocated by Skin.getAttachment. This is responsible for the big orange bottom part of your charts: the GC has to do a lot of cleaning-up.

I'd try two things: first, to see what would be the maximum FPS you could reach, remove those objects temporarily or (better) replace them with static images. Then you see the upper bounds of the potential you have here. Then, if that makes enough of a difference (I guess it does), perhaps you can look into that method yourself and try to find if there's something done that might be the reason for the high CPU time.

[bali33 note : if I remove my game spine animations the FPS reaches 60 FPS - no problem]

Some easy things to fix:

  • avoid any temporary objects to reduce GC load. In many cases, you can create a few static objects in a class and reuse them, instead of creating new objects repeatedly. Look at the Starling code to see samples for this (search for "helper object").

  • avoid "array/vector.push()"

replace with "array[array.length-1] = ...";

  • if there's an array/list access with a math operation, like this: "list[i+2]" add an int-cast like this: "list[int(i+2)]".

  • if there's a "for" loop, be sure to exchange:

for (var i:int=0; i<list.length; ++i)
with

var length:int = list.length;
for (var i:int=0; i<length; ++i)
Those are small things that sum up. These changes could be made without understanding much of the internal Spine logic. Just be sure to start with those methods Scout tells you are most important; and especially "Skin.getAttachment" to avoid all those temporary Strings.

Good luck!!!
Please keep me updated about your progress! :-)

Cheers,
Daniel