Questions about impact on performance

Hi,

I'm developing a mobile app. (Or, at least, in about 12 months' time of solid work that statement may be true.)

I'd like to understand that practical implication of certain things on performance. For all of the below, assume a 3D game in isometric view with simple objects and no fancy lighting effects.

1) If I use a bunch of GetComponent<> calls, I understand these can be "slow". How many is too many, inasmuch as they might affect the performance?

2) If my AI bodies use a bunch of raycasts (say, half a dozen each) to avoid obstacles, is casting a bunch of raycasts all over the place going to affect performance in a notable way?

3) If I build a level (let's call it a dungeon) and fill it with some AI (let's call it 20-50 mobs per level) and have them running from the point the player enters the level, will it affect performance?

4) If I save the player's progress into playerprefs or somesuch (so that, for example, he enters the above level and kills some of the AI, then goes to another level and does the same, and another and another x 10, then returns to the previous levels, is the game having to record the progress of 10x 20-50 mobs? Will that affect performance?

5) If I run particle effects on each mob, will it affect performance?

6) and, importantly, can I run a bunch of scripts doing stuff in Update(), or should I put coroutines in place everywhere instead?

etc...etc...etc

I know I can look at the profiler, but that requires me to have actually done the work. I don't want to do the work if it's going to swamp my game.

Basically, what I'm asking is what the game is capable of doing from a processing point without really taking a load, and what kind of stuff is going to kill the performance.

Thanks,

A

 

These questions are mostly nonsensical. ANYTHING you do affects performance. Do it a little, you don't notice. Do it a lot, it starts slowing your game down. Where "a little" and "a lot" are is all about the details.

The only question that's any different is this one, which is nonsensical for a different reason:

Coroutines run at exactly the same rate and overhead as Update(). I have found that in most cases, beginners tend to abuse them and create code that is harder to debug and maintain than if they just used Update, so I usually recommend the latter.

Alas, without a crystal ball, there is no way to avoid it. Your intuition about what will cause problems is wrong. My intuition about what will cause problems in probably wrong, and I've been using Unity for most of a decade. Intuition about performance problems is almost always incorrect, which is why profilers (and refactoring) were invented.

Also, I believe you have incorrectly identified the chief risk to your project. The chief risk is not that the frame rate will be too low. The chief risk is that you will never finish your project, probably because it will collapse under the weight of overcomplicated, unmaintainable code. This failure mode is extremely common.

So, when considering how to approach something, your first question should always be: what is the clearest, simplest way to do this? Then do it that way. Only if you can think of several equally clear and simple approaches, should you then consider which one will have the best performance.

Then near the end of the project, use the profiler and refactor the (probably surprising) hot spots you will discover.