- Editado
Spine-cpp memory usage much bigger than Spine-c
Hi guys,
After we changed spine-c runtime to spine-cpp runtime recently, our game use more memory than before. Does spine-cpp really take more memory than spine-c in design? or we made something wrong?
Many things in the spine-cpp API are classes using inheritance. As such, there'll be additional memory used for each object. This is something we can't really fix.
The spine-cpp runtime also uses a container class for data like timelines etc. which might add some overhead. This is something we can try to fix. I've created an issue here: [cpp] Reduce memory consumption · #1444
Hi badlogic, thanks for your quick replay.
I don't think the cpp classes memory consumption or the cpp container overhead can make sense. The screenshots above show the spine-cpp runtime take about 10M more memory than spine-c, it was cooked by one skeleton with 150+ animations, the .skel file is about 2.7M exported by spine editor 3.8.59. Our game memory consumption rise to 600M from 500M after change runtime to cpp. It seems like the cpp runtime store multiple data or some data should be destroyed but not. I am not sure, but I feel there must be something wrong.
If the the spine files I used can help you check the issue, I can send them to you.
The things I mentioned are the only differences between spine-c and spine-cpp. There's no duplicate data, or data that can be freed up entirely. I'll work on shrinking of containers. The vtable overhead in C++ objects is something I can't do much about I'm afraid.
I am not expert in cpp, don't know much about cpp container overhead, so I want to know if the spine-cpp works as expected? It should take so much memory? or if we should still use spine-c runtime for now?
spine-cpp does work as intended. As I said, there are a few minor improvements I can make for which I have opened an issue here: [cpp] Reduce memory consumption · #1444
Our game will be live soon, so we have to be back to spine-c for now. Thanks for you work, we will keep eyes on the cpp runtime.
And one more question, why you made spine-cpp runtime as the default of cocos2dx and UE runtime? Any document tell us the improvements?
We made spine-cpp the default for ue4 and cocos2dx as both use C++ in their APIs. This makes for a nicer integration. There are also a handful of language features that make spine-cpp nicer to use than spine-c.
On a side note: I would suggest to lock the version of Spine (both editor and runtime) for any project you work on. Updating mid-project, or as in your case, near to release, is bound to give you headaches.
Release is not the end, it's a start for our project. Before updating, we used spine 3.6.x for a long time. We think it's a good point to update spine before release. Now spine 3.8.x with spine-c runtime works well in our project. Actually it's not hard work to update spine editor and the runtime. The problem is spine-cpp, it makes our game crash on some low memory devices.
I also like cpp, it make work easy, lots of cpp code is in our project. but for more performance, we have to add some c code or shaders. For less memory, we have to split spine skeletons to multiple files, load them when needed and unload them when they are removed from stage, and we have to combine lots of uncorrelated spine texture to texture-sheets. And we have to think about the pixel format for every texture, RGBA8888, RGBA4444, etc1, or etc2...
What I want to say is spine-c (include ue4 and cocos2dx runtime) is value to be supported if it can work more performance or less memory usage. Of course, if spine-cpp can works better, it will be the best.
un mes más tarde
Sorry for this taking so long. I've found a bug in some of our allocation code. Now spine-cpp is slightly more memory efficient than spine-c 
I've benchmarked this with our cocos2d-x example project and the BatchingExample scene. Here's instruments for the 3.8 spine-cpp version:
Here's instruments for the 3.7 spine-c version from the 3.7-c branch:
Thanks for alerting us to this issue. You should be able to use spine-cpp without detrimental memory effects now.