Everything on Android is obscenely slow...

My game can't get a stable 30 frames per second on Android no matter what I try.

I've turned off collisions, commented out large portions of my scripts, pooled my objects... but the CPU performance is still terrible.

And using the profiler, I saw things that didn't make any sense at all. For example, an "Update" method that didn't even have a body was taking up about 10ms per frame. It was called on 500 objects, taking at least 30 microseconds on each one. Again, for a method that doesn't have a body.

There is also a large red "overhead" section in the profiler, and I haven't figured out what it means either.

On the other hand, on my PC it runs perfectly. Zero overhead, and about a millisecond for everything else.

Here is a comparison between PC:


And phone:


I understand that a phone is going to be slower, but it's a Galaxy S III; it has a 1.6GHz processor. It seems like something deeper must be going on here.

 

Calling functions such as Update takes time regardless of whether there's anything in the function or not. You should always remove any unused functions, regardless of platform.

--Eric

 

It's a function I do need. I just removed the body for the purposes of testing (meaning these 500 objects are now just sitting in the scene doing nothing).

But is 30 microseconds really a reasonable amount of overhead? I find that hard to swallow. I swear I've seen Android Unity games with many more objects than I'm using.

 

500 objects with active Update functions is a lot; you wouldn't normally have that even on a desktop. If you really need so many objects updated every frame, it would be more efficient to have a single Update function that loops through all the objects. Invoking Update on an object is relatively slow (compared to a standard function call) since it involves reflection.

--Eric

 

Hmm, that's disappointing... It seems like even if reflection is required to find the Update method, its information could be cached and put in a hash table or something.

Anyway, I could put my entire game's code in one "controller" behavior's Update method, but I thought that went against the design principles of Unity. All of the public properties of the MonoBehaviors used by the individual objects would need to be moved to the controller, making for a much less modular and less intuitive design.

But if it will fix the performance issues, I guess it will have to do. I'll give it a try and post my results.

 

Ok, I'm back. And to my amazement, doing some redesign and putting everything inside a single Update instantly shaved off that 10ms. Quite a shame that I'm forced to do this, but oh well.

 

Instead of moving everything to one controller behavior, you could create an interface with an update function named something besides "Update", and have the MonoBehaviors you need large numbers of implement that interface. You can then keep a list inside a controller object, and call the interface update function for each from within the controller object's update function. You would need a bit of code to add/remove the objects from the list, but you could keep all the variables inside the original MonoBehaviors.

Are you using skinned meshes? I have had some trouble with them on android

 

Hmm, so if I have a MonoBehavior with no function named "Update" I won't see that overhead? I haven't tested this yet, but if you're right, your suggestion would be more elegant than what I'm currently doing. Thanks.

 

My understanding is Unity uses reflection to search by name for the Start(), Update(), etc. functions and call them. This creates some overhead compared to calling the function directly, but I'm not sure how much. If you are interested, you can read an intro to reflection at http://csharp.net-tutorials.com/reflection/introduction/