I'm having a problem of Spine calling GC.Alloc a lot while instantiating new objects into the scene while the game is running.
I've went through version history and supposedly the problem was adressed in latest runtime update (3.7 ish) but unfortunately after updating the runtime and reexporting skeletons problem still appears. It consumes over 25 ms which is not acceptable.
Is there any workaround/fix for that?
grzegorzdalek escreveuI'm having a problem of Spine calling GC.Alloc a lot while instantiating new objects into the scene while the game is running.
I've went through version history and supposedly the problem was adressed in latest runtime update (3.7 ish) but unfortunately after updating the runtime and reexporting skeletons problem still appears. It consumes over 25 ms which is not acceptable.
Is there any workaround/fix for that?
How do you check that? I'd like to check mine to see if the same is happening
We just noticed performance drop while playtesting the game. We have one frame calculate in < 5ms so having additional 25 is noticeable. It was happening while we spawned another skeleton with death animations, and we went through Profiler to find it.
Right now we're solving the problem by "prewarming" and pooling the death animations just after the level is loaded, but it's dirty workaround.
This is indeed unacceptable! Are you using SkeletonAnimation, SkeletonGraphic or SkeletonMecanim? Could you please describe how you instantiated your objects - was it via prefabs that are instantiated (I assume so) or via SkeletonAnimation.NewSkeletonAnimationGameObject()?
I will have a look at it, however any info on the subject will speed up the process of resolving this issue - so if you could create a zipped package of a minimal Unity project that shows this problem and send it to contact@esotericsoftware.com, that would be very helpful!
I have profiled some stress tests and have on the one hand seen many but very small allocations (for the Bones), where all allocations for 60 simultaneously instantiated Spine-Raptors took 0.5 ms in total.
Are you really getting 25ms from a single instantiation? Or do the 25ms come from GC.Collect calls, which might be due to other larger allocations of your game being cleaned up? Maybe there is a problem somewhere else hiding in the shadows, since the small allocations would not cause any fragmentation issues.
Right now we're solving the problem by "prewarming" and pooling the death animations just after the level is loaded, but it's dirty workaround.
Prewarming of an object-pool is a perfectly valid way and pretty common as well, especially in Unity due to it's 'suboptimal' garbage collector. Allocation-wise you will be able to predict much better how many instances of each object will be active at any time than any framework could. Plus creating vertex buffers of the proper size, etc will always take it's time and should be moved to load-time of a scene as much as possible.
