Performance problem with modifying transform.position

Unity Engine
1

I have a component that only performs the following operation:

transform.position += m_velocity * Time.deltaTime;

And it does this every frame (inside Update). I have about 150 gameobjects with this component. Somehow this is consuming about 0.4ms per frame on my macbook pro. This seeks a bit odd. Any idea for why the cost of doing an addition and multiplication is so high?

2

It’s nothing to do with addition and multiplying, it’s accessing transform. Cache the transform component and you will get some speed increase. Additionally, having 150 separate Update calls is quite heavy.

–Eric

3

so for like an rts with lots of units whats the proper way to get the performance? instantiations? pooling? kinda at a fork here myself on this issue…

4

Pooling and an object manager.

A single script, with a single update file, and using List to manage a class, like traditional game development.

Class RTSUnit
{
pos:Vector3;
etc
}

List of above class

loop through list, update them.

What eric said about caching transform is also vital, that would go in your class too.

5

thanks hippo, your posts are always rlly helpful.

6

I’ll try it, but I’m failing to understand why caching the transform would create any savings. I’m already calling transform.position, doesn’t that mean the transform is already cached, and I’m accessing the cached transform?

7

These two are equivalent I believe:

curTransform = gameObject.GetComponent<Transform>();
curTransform = gameObject.transform;

So you’re effectively calling GetComponent every time you access transform. Doing one of those then using curTransform.position should be much faster than transform.position.

8

Nope, as niosop explained. (The Unity docs do explain this, under the performance section.)

–Eric

9

Its an inconsistency in UTs naming scheme and complying to the standards the have choosen to follow as properties would start with upper case not lower case

Any confused user or user on missassumptions is one that UT has consider their error due to their coding practises failing, not the user failing on reading anything (as it has been like this since Unity 2, I would suspect they were just not willing to fix this error on their behalf on the U 1.x → U 2.0 transition when only a few thousand users would have been a affected with it originally starting out as variables on U 1.x but invisibly being switched to props)