Native iOS code runs slower with Unity

This is a very specific problem I'm facing when working with a native iOS library and Unity3d. The performance of the library goes down 2-3x times when we integrate with Unity, as compared to when the native code is built as a native app (without Unity). The native library basically spawns a separate thread and performs some image processing computations. Both the with and without Unity versions calls the same library code. The without Unity native app renders some OpenGL primitives using GLKit. In XCode I can see performance (in terms of CPU use) of either app being the same when the native library code is not running. However, native code takes 2-3x times in the app that has Unity integrated. I'm using IL2CPP builds here.

Could there be anything in Unity that prevents native code from running slower? Or, does Unity prevent parallel threads to use less resources? (Unlikely, I know, but I've run out of ideas for now).

 

How is the library perf with a simple repro (empty) project with and without IL2CPP, to rule it out? if the IL2CPP version is indeed slower in this test case, Unity would love to have a bug report on it to iron out IL2CPP issues. There are cases where it's been periodically slower.

Chances are it might not be though, and hopefully someone more experienced in this area can chime in...

 

Unfortunately the native library is built only for arm64 - so can't test without IL2CPP. Will see if I can get hold of an arm7 version to test that.

Since the native library uses multiple threads internally, I'm thinking maybe it is fighting with Unity's set of threads in terms of CPU resources. If that's the case, any chance that the number of threads Unity has running can be minimized?

Thanks for the quick reply!

 

There's also the overhead of just Unity itself - have you accounted for those numbers?

 

Yes. When the native library doesn't run, CPU usages are very similar 40% (+-2%) for both the apps. Checked the threads now - Unity has 21, native app has 9, without the library running. Will keep looking into this.

 

OK, I found a solution to this - switching to Metal brought the Unity plugin code performance up to native code performance. Number of threads did not have anything to with this apparently. I am not sure why switching to Metal would make native code perform better with though.