koobas.hobune.stream
Huge GC Overhead When Accessing Tris/Verts From Mesh?
Hey everybody. I ran into this problem when I was looping through some meshes in Unity 4.0.0f7 I never noticed if the other versions did this as well. Unity took 10 seconds just to loop through the triangles and vertices in my scene. I opened up the profiler to find out what was so slow. It appears that there is a huge garbage collector overhead when using Mesh.triangles[i] and Mesh.vertices[i]. I was writing an editor script to loop through all meshes in my scene, which was not very complex. The garbage collector generated OVER 1 GB of garbage, and used almost all of the cpu, JUST from accessing triangles via Mesh.triangles[i].
For a simple test, I attached this script to a Unity sphere and got these results in the profiler.
using UnityEngine;
using System.Collections;
public class MeshTest : MonoBehaviour {
public Mesh mesh;
void Start() {
Vector3 v1;
Vector3 v2;
Vector3 v3;
for (int i = 0; i < mesh.triangles.Length/3; i++) {
v1 = mesh.vertices[mesh.triangles[i]];
v2 = mesh.vertices[mesh.triangles[i + 1]];
v3 = mesh.vertices[mesh.triangles[i + 2]];
}
}
}
The script loops through each triangle and gets its vertices. Nothing more. As you can see, the garbage collector eats up most of the cpu. Its not possible for me to loop through meshes bigger than a sphere if accessing mesh data is going to be so slow. Anyone know if there is a work around? Or if this is a bug? I tried using Array.Copy and Array.Clone, so I wasn't accessing Mesh.triangles directly, but it had no effect. Any insight would be appreciated.
I think this happens because your for-loop is acquiring a new copy of the entire triangles array every time it iterates because it has to re-evaluate the termination condition:
for (int i = 0; i < mesh.triangles.Length/3; i++) // Re-fetches the triangle array
{
}
Without wanting to assume too much knowledge of the internal workings of the Mesh class, I suspect the Mesh class returns deep copies of its data arrays (including colors, normals, vertices and triangles). That's why these are properties (rather than public fields), and it's why you have to re-assign arrays back to the Mesh after edits; you're working on a copy after accessing it.
In your code, the for-loop checks the length of the triangles array by continually accessing it, so every time the for-loop iterates, the Mesh's triangles property is probably creating a deep copy of the entire array before returning it to the for-loop. That's what generates the huge GC overhead.
To test if this is the case, move the access to mesh.triangles outside the for-loop and store the Length in a local variable, then test against that in the for-loop instead.
You're right! I spent an hour last night messing with this. Reassigning the arrays, copying them, cloning them. Just to realize that I forgot to change one of my for loops that was still accessing mesh.triangles. DOOOH! Thanks for helping me realize that! Its the dumb mistakes that always get me -_-
Exactly. To be more precise in each iteration you create 4 triangles-array copies and 3 vertices-array copies.
Btw: If you plan to modify the vertices multiple times you should keep the vertices array in memory, change it and just re-assign it. Unity will still have to "copy over" the data, but it doesn't create a new array each time.
Yeah, I realize I was inaccurate in the answer. I only saw afterwards that multiple accesses were taking place in the loop body as well. :)
Btw. Stumbled over the same problem, but I only needed to read the vert. info, so instead of
Vector3 myVec = Vector3.zero;
Vector3[] normals = mesh.normals;
int length = normals.Length;
for (int i = 0, i < length; i++)
{
Vector3 normal = normals[i];
// do something
}
I used
foreach (Vector3 normal in mesh.normals)
{
// do something
}
which was basically realtime for a 50k vert mesh.
