[Unity]SketetonGraphic.LateUpdate() very slow in debug.

wangyin215

Hi, Dear Spine Time:
I use unity runtime. When I deployed the project to the iPhone XR real machine (debug mode), I found that the fps was very low. Through the profile tool, I found that SketetonGraphic.LateUpdate() occupied 22ms in one frame, resulting in a reduction to 30fps. I tried to check in the release mode and found that it can run stably at 60fps, which shows that the runtime has no performance problems under the release mode.

My question is that only I can use the profile tool to optimize the performance of the game in the debug mode, but in this mode, the running performance of SketetonGraphic.LateUpdate() is far from that of release, which will affect our work of optimizing the number of frames and energy efficiency. Is there any way to improve the running performance of the spine runtime in the debug mode?

PS: In the above scenario, there is a spine character and several UIs. Please see the attachment for spine metrics.

PS: In addition, another screenshot of the attachment is the status in the unity profile.

Harald

wangyin215 yazdı
My question is that only I can use the profile tool to optimize the performance of the game in the debug mode, but in this mode, the running performance of SketetonGraphic.LateUpdate() is far from that of release, which will affect our work of optimizing the number of frames and energy efficiency. Is there any way to improve the running performance of the spine runtime in the debug mode?

Good question. While we haven't tried that yet, it should be possible to use a release build of spine-csharp by creating a separately built dll (in Release config) instead of using .cs code files.

To do this, you would need to:

Create a new .net Class Library using Visual Studio (matching the .net version settings of your project settings, under Player - Configuration - API Compatibility Level, e.g. 2.0 or 4.0).
Then add all source files from spine-csharp to the project
Build the project in Release configuration.
The output .dll can then be used to replace the content (all .cs files) of the spine-csharp directory. I'm not sure the dll needs to be placed in a subdirectory named Plugins any more, but it should not harm either.

The release DLL will still be missing some benefits of e.g. IL2CPP performance boost and the like, but it might improve the situation.

If you decide to go down that road, please let us know if this improves the situation in your case.