Performance issues with large numbers of gameobjects

I've found that the number of gameobjects is a bigger performance factor than the number of vertices. If I have several thousand GOs with only a few vertices apiece, it runs a lot slower (by several orders of magnitude) than a few GOs with thousands of vertices apiece, which seems counterintuitive. Does anyone know why this happens and what I can do about it? I need a large number of separate objects which can be moved around independently, so I don't have the option of combining them into larger meshes.

 

Does this occur in build or only in Edit mode? Note that the Editor adds overhead (eg.needs to update the hierarchy). In Editor you could make them hidden in the hierarchy and parent most of them to a visible node so they don't get lost hidden.

 

I only tested it in the editor. Would the problem be expected to disappear in the build? I'm surprised there isn't more information about this, since I would think it would have to be a common situation.

 

Asset serialization...each go has to be serialized and then deserialzed.
This is unity engines fatal flaw...R/W operations from virtual memory to disc.

This excercise accentuates that flaw....
I just started learning about this, with a very large project..

 

Even having a gameobject, that has many components, selected will cause great amount of lag in the editor since the editor needs to draw all those components or run code in the background.
I made it a habit to have nothing selected when playtesting in the editor.

This doesnt have to be a editor problem though. Do you have a dynamic light in your scene? High draw calls count? I pretty much need to disable any dynamic lights / shadows and just use baking since my computer isnt great. Try disabling your directional light and see if performance increases.

 

@HonoraryBob
I guess, you are asking basically, why more draw calls are slower than fewer draw calls?
http://docs.unity3d.com/Manual/DrawCallBatching.html

 

Yep. The number of vertices is not the only factor in the cost of drawing. The cost to start drawing each object is significant. On the CPU side, the cost is entirely based on the setup of draw calls and the number of verts can be irrelevant (except for CPU skinning and stuff like that). On the GPU side, getting a draw to start can take as much time as 50-500 verts depending on the details.

So, with the simplified mental model of each object having a hidden 100 vertex cost, 1000 objects vs 10 objects adds the cost of 99,000 verts to your scene on the GPU alone.

On the CPU side, it wasn't long ago that Civilization V was giving technical talks to brag about managing to handle 10,000 draws per frame in D3D11 on a high-end PC via highly specialized rendering code.