# XNA mesh.Draw() takes the longest CPU time

We have a problem. Our game steadily slows down as we increase the number of models we draw. When the number reaches 100 - FPS is dead. Our humble tests showed that the reason is not GPU. This is what we did:

• Rendered models with the most basic shader code - nothing changed;
• Checked the NVidia NSigt metrics - GPU was less and less loaded per second as we increased number of models;

At the same time, a simple Windows Task manager showed that, as the number of models rise, the load increases (up to a 100%) on the single CPU core that our game uses. So we are pretty sure our game is running slowly because of the CPU.

We then moved on and tried to identify which line exactly causes the problem. We used c# TimeSpan metrics and timers for that. Our research showed that the biggest cause of the slow performance is... mesh.Draw() function used by every model that we draw.

We tried commenting this very line and things improved instantly (ofc. nothing was drawn on the screen).

So the question is, what are we to conclude from this? mesh.Draw is a closed function and we cannot optimize it. Trying to bruteforce parallel it is impossible (i guess it was natural). But something tells me that we need to look elswhere if this function is slowing the CPU, the question is where?

Update: here is the code I use to draw the model: public void Draw(...) { int index = 0;

            int i = 0;

foreach (ModelMesh mesh in Actor.Model.Meshes)
{

bool isDrawable = false;
#region Check if this ModelMesh needs to be drawn according to PartsToDraw (string) list.
foreach (string s in PartsToDraw)
if (s == mesh.Name)
isDrawable = true;
#endregion

if (isDrawable)
{
int effectStartIndex = index;
foreach (Effect effect in mesh.Effects)
{
if (Actor.MatrixPaletteParams[index] != null)
{
Actor.WorldParams[index].SetValue(World);
Actor.MatrixPaletteParams[index].SetValue(Actor.Palette[i]);
}
else
Actor.WorldParams[index].SetValue(Actor.Pose[mesh.ParentBone.Index] * World);

if (drawType != null && drawType.DrawShadow)
else
{
SetCommonEffectParameters(effect, renderer);
SetLitEffectParameters(effect, renderer, drawType);
}

index++;
}
}
else
index++;

if (isDrawable)
mesh.Draw();

i++;
}
}


"Set...EfectParameters" methods mostly consist of effect.Parameters["SomeParameter"].SetValue() calls. I pass around 30 parameters to the GPU there, mostly floats, matrices and bools. Moreover each ModelMesh has three textures that it passes into the GPU. I have no idea how fast this works and if it can be optimized. It should be fast.

You should also note that I draw a skeletaly animated model using Dastle's XNA Animation Component library. Once again, I understand that this might be the reason behind lags, and we did find the weak spot of the animation code, but why on Earth does the metrics show that mesh.Draw is the slowest spot? What is happening there?

• Is this in a release build? I kinda remember that function being quite slow in debug mode. – Roy T. Dec 4 '13 at 10:21
• Wow, we will check the release build now, hang on... – cubrman Dec 4 '13 at 10:23
• Draw commands are bound to be slow, thats why you try to pack and minimize statechanges, drawcalls as much as you can. – Tordin Dec 4 '13 at 10:27
• Ok, ok but WHAT should I concentrate on? Should I try to reduce effect.Parameters calls? I know that instancing is the way to go, but I debugged Sait's Row 4 with NVidia NSight and saw that they use NO instancing whatsoever, and it runs at INSANE speed with over 4000 draw calls (can't remember acurately but the timeline was COMPLETELY blue while in our game it has a number of thin stripes across it's white background). – cubrman Dec 4 '13 at 10:33
• Yes, thats common. A modern engine can easily draw ~10k drawcalls just fine. It´s hard to say with outseeing any code. if you could update with your draw code and how you traverse on your sceen it would be greate. – Tordin Dec 4 '13 at 11:09