# Is it normal that “Game.Run” in XNA uses a lot of resources?

I have been using the visual studio profiler to optimize my game. I have noticed that the Game.Run method is eating through 93.6% of the overall game resources.

Is this because all of the other functions are called by it in the game? Or is there a problem? I am quite new to the VS profiler and have in the past not used such applications to assist in optimizing.

Xna probably calls Present in it's body and this is just tells you that the application hangs 96% of the time waiting for the vertical sync -> doing nothing. The task manager should report a low cpu usage too. It does not look like any optimization is necessary yet, at least not on the machine you are running it on.

Deactivating vsync should shift it to the Update/Draw functions.

Question though is there any game performance advantage having the Vsync On?

Vsync off basically leads to frames getting rendered that will not be displayed at all, as the display only updates in a fixed interval, most commonly 60hz. This wastes processing power/electricity and leads to presents getting issued while the display is receiving the last image which leads to an effect commonly known as tearing. On the other side activated vsync leads to an increased input latency of up to 1/fps seconds, which is very notable in some games, eg ego shooters, when using absolute input devices like a mouse or head tracking.

• Thanks that was really helpful. Just set IsFixedTimeStep = False and i noticed game.run() pretty much disappeared from the profiler output. I can now focus on trimming as much fat as i can. Question though is there any game performance advantage having the Vsync On? – Ree Feb 17 '13 at 22:31
• @davidallan VSync Off: Run as fast as possible (waste GPU and CPU time), VSync On: Run as fast as necessary (wait for the monitor to actually display the data you have calculated, without it the GPU will draw lets say 200 frames each second, but will only display 60, because the Monitor simply can't be faster) – API-Beast Feb 17 '13 at 22:47
• Added some additional information regarding vsync. – Archy Feb 17 '13 at 23:37
• Thanks for the detail, i started to notice some tearing, was able to correct the tearing by making sure everything drawn was in sync in the game. Vsync on seems like a better option. However when debugging it seems like i can get more info about where i can try and cut down processing in the draw and update loop(as you mentioned with Vsync off they will both run flat out). Thanks for the info :). – Ree Feb 18 '13 at 20:59
• If you was using fixed timesteps and now you disabled it that may introduce another kind of problems later. For example, if your simulation used constant values, for example to advance player character position, now you have to take into account the delta between frames, that may vary each frame. Only a comment, maybe you are already aware of it. – Hatoru Hansou Feb 18 '13 at 22:04