Perfomance issues XNA versus Monogame

PhiConst.NET · March 27, 2016, 4:04pm

Hello dear friends,
I have ported my minecraft clone to the Monogame framework and realized some little perfomance issues : Chiefly while generating the world; in XNA the generation for a 13x13 chunk-map (each chunk has a width and depth of 13 and a height of 256)
takes 0.67 seconds, in Monogame 2 !.

How can I optimize the code to achieve the same speed as in XNA?

I thank you in advance.

Post scriptum: The FPS is mostly similar(in comparison to xna), just the world-generation takes a “bit” longer.

mgarstenauer · March 27, 2016, 6:06pm

You can analyze your code using a .NET performance profiler (such as Visual Studio, Redgate ANTS Performance Profiler, Jetbrains dotTrace, …) and find out how long each function is taking.

I suggest you create a performance profile of the XNA app and the MonoGame app and compare the profiles. If a MonoGame function is causing the slow down, you can create a new issue on Github.

Tom · March 27, 2016, 7:01pm

That makes me suspect the issue is the VertexBuffer/IndexBuffer SetData calls.

Let’s see what a profile shows.

PhiConst.NET · March 27, 2016, 10:30pm

I am sorry, my Visual Studio is only giving me these kind of information and analyzing processes.
The Monogame-versions are these with the titel “MinecraftCloneMonogame”.

Thank you in advance!
215

Tom · March 27, 2016, 10:36pm

Looks like you only got the memory profile for the MonoGame build… that won’t help us. Like in your XNA build you need to look at the performance profile.

PhiConst.NET · March 27, 2016, 10:41pm

Uh, I guess, I know why.
The ContentPipline:

The picture above is in monogame.
Here are the results for XNA:

PhiConst.NET · March 27, 2016, 11:16pm

I am sorry,
here is the perfomance profile for monogame:

Tom · March 27, 2016, 11:17pm

Those images still don’t tell me anything. We don’t need any memory profile images… memory usage isn’t going to tell us why it is slow.

The “Functions Doing The Most Individual Work” charts are what we need to see.

You mean on XNA VertexBuffer.CopyData is doing the most work and in MonoGame ContentManager.Load<Texture2D> is?

PhiConst.NET · March 27, 2016, 11:19pm

I did realize that I have uploaded the wrong screenshots.
My recent post shows the perfomance profile.

Tom · March 27, 2016, 11:34pm

That seems like vertex/index buffer writing is the issue… SharpDX.Interop.Write is used for that.

Can you look at the Function list? It should show a lot more data.

PhiConst.NET · March 27, 2016, 11:59pm

Not that lot;
here is the hierarchy:

btw: Very nice editor !

nkast · March 28, 2016, 2:29am

Can you change to x64 and profile again?

Tom · March 28, 2016, 12:16pm

How are you building your vertex buffers @PhiConst.NET? Can you show us how they are allocated and roughly how you are calling SetData?

PhiConst.NET · March 28, 2016, 3:49pm

It’s 64x profile( because these chunksarrays are greater than 2 Gigabyte).

@Tom
I will upload the XNA and Monogame source to github.
I guess it’s the best way to demonstrate the problem.

See ya in _ 5~15 mins.

PhiConst.NET · March 28, 2016, 4:09pm

http://pastebin.com/RAjLM3BM

PhiConst.NET · March 28, 2016, 4:34pm

EDIT; It’s the VertexBuffer:

github.com

NET-D3v3l0p3r/Minecraft-Clone-Monogame-obsolete-/blob/498a49602999e2c31edd8109ebe09f6c8392568e/MinecraftCloneMonoGame/CoreObsolete/Misc/BoundingBoxRenderer.cs

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MinecraftClone.Core.Misc
{
    public static class BoundingBoxRenderer
    {
        static VertexPositionColor[] verts = new VertexPositionColor[8];
        static short[] indices = new short[]
	    {
		0, 1,
		1, 2,
		2, 3,
		3, 0,
		0, 4,
		1, 5,

This file has been truncated. show original

The method: UpdateBoundingBox.

IF I REMOVE IT: 0.6 SECONDS!

PhiConst.NET · March 28, 2016, 4:47pm

It’s the Method GetData not SetData!

github.com

NET-D3v3l0p3r/Minecraft-Clone-Monogame-obsolete-/blob/498a49602999e2c31edd8109ebe09f6c8392568e/MinecraftCloneMonoGame/CoreObsolete/Misc/BoundingBoxRenderer.cs#L94


foreach (ModelMeshPart meshPart in mesh.MeshParts)
{
    // Vertex buffer parameters
    int vertexStride = meshPart.VertexBuffer.VertexDeclaration.VertexStride;
    int vertexBufferSize = meshPart.NumVertices * vertexStride;


    // Get vertex data as float
    float[] vertexData = new float[vertexBufferSize / sizeof(float)];
    try
    {
        meshPart.VertexBuffer.GetData<float>(vertexData);
    }
    catch { }
    // Iterate through vertices (possibly) growing bounding box, all calculations are done in world space
    for (int i = 0; i < vertexBufferSize / sizeof(float); i += vertexStride / sizeof(float))
    {
        Vector3 transformedPosition = Vector3.Transform(new Vector3(vertexData[i], vertexData[i + 1], vertexData[i + 2]), worldTransform);


        min = Vector3.Min(min, transformedPosition);
        max = Vector3.Max(max, transformedPosition);
    }

If I remove this method from DefaultCubeStructure… it takes 0.6 Seconds to generate the world.
With UpdateBoundingBox over 3 seconds!

Tom · March 31, 2016, 1:41am

You should really avoid calling GetData on any graphics resource… you are literally copying data back from GPU memory to CPU memory. This is not very fast at all.

We could maybe optimize things a bit more there, but DX11 is different from DX9 and it may just never be able to get the same performance as XNA with this. Even then… it will always be slower than already having this data in CPU memory… regardless of XNA or MonoGame.

PhiConst.NET · April 1, 2016, 1:56pm

Yes, that’s right.
Thank you man.