XNA game performance

Asked 27/8, 2011 at 22:21 Answered 28/8, 2011 at 11:27

I am writing a game using C# 2010 and XNA 4.0. I want it to be a good game and not some "just another crap" and so one of my goals is good framerate. For this I would like to ask you for some advices, be it XNA related or C# related - what can I do to speed up my code and so improve FPS.

Here is some stuff I found out:

(c#) using array insted of list<> will improve performance a lot, in case you want to access huge amount of data (or even lots: having an array of 20000 items gave almost 180% FPS of list of 20000.
(c#) using for instead of foreach will improve performance. On same 20000 elements it's like 5-10% difference.
(xna and c#) calling methods costs performance, so when I scattered my code into methods what called other methods and such, and everything was so cool and object oriented it was on the cost of 1-3 FPS each call.
(xna) update vs. draw: it was no difference in performance when I put code into update() and draw(), so if you do not care much, you do not have to put some methods under update() instead of keeping everything together in draw() in hope of better FPS.
(xna) no idea if it is me or just 4.0, but when you load a .X with lot of textures in it and pretty complex meshes, it takes a LOT of time to load. I had to write my own .X loader and mesh/model renderer just because XNA started to load texture for each and every triangle regardless if the previous one had the same texture to it. Even writing my own contentloader which caches textures for you is no solution, because it is still utilised a lot of times. If you make something nice and fluffy I suggest using drawuserprimitives and not Model class. (no idea if it is 4.0 only, or 3.1 had such performance problem too)
(xna and c#) Try to avoid using "new" when it is about drawing. I saw some code around on web, what was copy/pasted together and had "basicEffect = new BasicEffect(graphicsDevice);" and such uglyness in the draw(), and even worse: in iterations inside draw(). Such will kill performance. Instead of this have one such class in "game" or in a static class. This applies for other "temp-objects" too: ugly but I think it is better to create something global and use it with attention then to make a nice and fluffy code what will make our game because of garbage collector.

Ok, so to make long story short, please post some good advice here, so I / we can make good, fast and optimized games ;)

Thanks in advance: Zéiksz

Pyroconductivity answered 27/8, 2011 at 22:21 Comment(11)

Seems like a good CW candidate :) – Ranket 27/8, 2011 at 22:23

I'd recommend making this a community wiki. – Sternum 27/8, 2011 at 22:24

I don't buy that using a solid OOP architecture costs 1-3 fps each call... – Tachyphylaxis 27/8, 2011 at 22:35

Even calling an empty method without parameters and such eats lil bit of performance in a draw/update - my suggestion was to keep code together (and so: GC-free). – Engineering 27/8, 2011 at 22:40

What does the GC have to do with it? IF you use the same objects you'll allocate the same memory, be it in a single function or not. Functions don't get GC'd. – Tachyphylaxis 27/8, 2011 at 22:45

Really? Are you experiencing a problem? Or is this an other case of pre-optimization? BTW, List<T> is backed by an array, you're probably initializing it with a default capacity of 10: #2540550 – Oneil 27/8, 2011 at 23:33

No, I do not. Just made an iteration for 20000 elements and found out that for with array is faster then foreach with list, much faster, and I thought it would interest someone else too. – Engineering 28/8, 2011 at 8:31

I'll note that foreach can use an IEnumerawhatever<> interface depending on the collection and that -can- trigger a GC. But the part about structuring code into methods doesn't make sense. The compiler should inline where appropriate, and you could force it to even if it didn't. – Stagecraft 10/4, 2013 at 23:49

@Tachyphylaxis I'm not backing Zeiksz's claim, and I haven't looked into this, but with a decent rig XNA can render at thousands of FPS (I think my computer pushes about 10k FPS with nothing but a blank screen being drawn; this is with an HD 5850 from '09 I believe.) so perhaps shaving off 1 FPS for a function call isn't so unbelievable. – Wurst 7/8, 2014 at 13:20

@FreeAsInBeer, hell yes it is, just do a little math of how many operations per second a modern CPU does (it's in the billions and more) and how many cycles it takes to call a function (it's about 4-5 asm instructions). – Tachyphylaxis 7/8, 2014 at 18:10

I'll have to agree with Blindy and Dave here. We should rely on compiler to optimize method calls instead of compromising OOP practices. Especially since we have the option of forcing it with the relevant attributes. – Frawley 11/10, 2016 at 16:18

UberGeekGames has a good article on XNA optimization. It's mostly targeted at Xbox and WP7, but many of the things also apply to PC.

~~http://www.sgtconker.com/2011/05/high-end-performance-optimizations-on-the-xbox-360-and-windows-phone-7/~~

Original site is dead, but is available in the Internet Archive:

Archived version of High end performance optimizations on the xbox 360 and windows phone7

The rule of thumb is "profile before optimizing".

Hyperplane answered 28/8, 2011 at 11:27 Comment(1)

Site seems to be dead as of 24 AUG 12. – Penang 25/8, 2012 at 3:13

Software optimisation is a craft. The best kinds of optimisation are evidence based on collected statistics.

Until you have a problem don't optimise. Don't you think that game playability is more important than this metric or another? My suggestion is make the game first and then consider where it's not performing as you'd like.

Then post some specific questions and I'm sure you'll get some help here on the specific issues.

In the mean time I suggest that you'll get more information from games development books like those listed here : http://forums.create.msdn.com/forums/p/8642/45646.aspx.

XNA Extereme 101 - seems to be an interesting tutorial

Methoxychlor answered 27/8, 2011 at 22:27 Comment(4)

I would agree that pre-programming optimization is no-no. But I think having a question/answer for people who are running into this issue would be helpful. – Cida 27/8, 2011 at 22:30

@erik -I agree with that too. It's a good place to collect this info. – Methoxychlor 27/8, 2011 at 22:33

+1 I completely agree with this answer. People that are running into performance issues are almost certainly doing something severely wrong and should either run a profiler to find it, or post about the specific problem. If you're having issues, merging half of your method calls is NOT going to help. – Oneil 27/8, 2011 at 23:57

Thanks for advice, but I still think that knowing something prior implementing some other way badly is better then optimizing afterwards with possible need of an overhaul. Asked my question to know what to pay attention while programming. – Engineering 28/8, 2011 at 8:37

My 2 cents worth:

Don't put all your code in one method because you think it costs to call a method. If you THINK your losing 1-3 FPS by calling an empty method, You probably haven't finished researching the 1-3 loss yet. For that loss to be true during an empty method call, you'd have to have a FrameRate in the MANY thousands.... where you wouldn't concern yourself about a 1-3 drop.

FPS is a bad way to judge performance in XNA. When you have variable time step enabled, other processes that the OS is involved with can influence your frame rate. You really need to profile instead. Just concentrate on the amount of time it actually takes to complete the Update &/or Draw Methods by timing them with a System.Diagnostic.Stopwatch object. time them individually, not together (very important).

The 'new' keyword should not only be avoided in the draw call but anywhere in both the update & draw... FOR reference types only. Use the new keyword anytime and anywhere you need to with value types.

House answered 28/8, 2011 at 0:42 Comment(0)