Performance issue on simple script

I made this very simple script to generate a fake motion blur :

Code (CSharp):

1. public class NewMotionBlur : MonoBehaviour {
2.  
3.     List<float> Xpos = new List<float>(new float[101]), Ypos = new List<float>(new float[101]);
4.     GameObject[] Sprites = new GameObject[10];
5.     public GameObject Trail;
6.  
7.     void Start () {
8.         for (int i = 0; i < 10; i++)
9.                 (Sprites[i] = Instantiate(Trail, transform.position, Quaternion.identity) as GameObject)
10.                     .GetComponent<SpriteRenderer>().color = new Color(1f, 1f, 1f, 1f - ((float)i) / 10);
11.     }
12.  
13.     void Update () {
14.         Xpos.Add(transform.position.x);     Xpos.RemoveAt(0);
15.         Ypos.Add(transform.position.y);     Ypos.RemoveAt(0);
16.         for (int i = 9, j = 0; i >= 0; i--, j++)
17.             Sprites[i].transform.position = new Vector3(Xpos[j * 10 + 10], Ypos[j * 10 + 10], 0.5f + ((float)i)/1000);
18.     }
19. }

And the output is nice if placed on the circle that you see in top left corner of this screenshot :


The problem stay as long as that object exist, i see at least a 30% loss in performance and the player jump script (which uses rigidbody2d's y velocity) seems to get much higher than predicted

PS: yes, everycube is a pre-instanciated gameobjects with just a collider attached, i was trying to make a terraria style generated terrain

 

Most obvious issue I see here is how you add/remove an object from the Xpos Ypos arrays at every update.

• Xpos.Add(transform.position.x); Xpos.RemoveAt(0);

• Ypos.Add(transform.position.y); Ypos.RemoveAt(0);

Don't do this.
Try disabling the script (uncheck it) while running and that basically tells you the overhead of your update function.

One possible way to do it is, at each frame you take the last game object in the trail and make it the first (by moving it and updating transparency) so that you only update the coordinates of one game object (though you still need to increase transparency for all). In pseudo code it might look like:

for each GO:
-- reduce alpha
-- if alpha < threshold:
------ set position to parent transform position

I think there would be a more efficient way to do it but with this your performance issue is likely to disappear.

 

Is it really an expensive operation ? I do understand it has to reallocate all the previous entry but we're talking about floats, and the size of the internal array never gets changed and stay fixed to 101 floats each frame

 

See my update answer above, and compare for yourself?

I'm not sure how it's handled internally but I don't see a proof here that the internal array size never changes, or that it's not creating and deleting objects to box-unbox your floats....

 

Actually is better but not enough to justify the decrease in performance and I lose the trailing effect were each faded copy smootly followed the lead.. btw as far as i know lists internal array gets resized as soon as it exceed it's compiled set capacity, as long as it remains to a fixed size (101 in this case) it isn't reallocating all the members to fit a greater array (but as you said the overhead still exist as long as it'll need to move 100 floats backwards when I delete the first)

 

Yes, very hopefully the internal array (from MSDN docs it looks like its stored in an array) won't be resized as long as you don't exceed capacity (assuming a fairly classic implementation) and even then this shouldn't happen more than once.

So, what happens when you disable the script? Running the script for a bit (to get the trails to appear) then disabling it should allow you to confirm the overhead of the update function itself (versus, say... rendering the graphics... which theoretically shouldn't be relevant but... we're trying to isolate something quirky, right?).

The implementation I suggested is very simple, admittedly won't reproduce exactly your original effect. Even though... surprised that you still see a significant overhead.

Break down your original update into more lines of code so you can comment them out to compare overheads.

I insist, beware of assuming that "just floats" makes any difference here. Storing primitives may require creating and discarding wrappers, which you really should avoid inside Update as it will bite you eventually.

Are you bothered posting the updated code? Or quantifying your overheads? imho just the process of digging up more details to explain your problem will point at the right solution.

 

Also can you not cache your transform?

 

What you mean exactly ?

 

Well actually the script is just the one I already posted, there's another one attached to that gameobject to make it rotate around.
Anyone knows a way to measure fps ? Unfortunately I'm not using the pro version's profiler and can't tell in numbers the real frame loss from this script alone

 

Here.

 

Uh, no. Don't use fps it's practically worthless. Use millisecs.

 

How exactly ?

If that script is reliable we were both right since it stay fixed to 60 fps no matter what (I know you'd like to kill me after earing this)
Then in this case it is just my eye that cannot distinguish from normal to drop rate fps

 

That's why you use millisecs.

http://forum.unity3d.com/threads/timing-how-long-a-function-takes-to-do-its-thing.180167/