malignate88

Hi,
I recognized, that my framerate is very bad in comparison with some C++ examples. After removing all "catchs" in the render-methods i got 100 FPS instead of 20. Exceptions seems to be really, really slow. Are there some other performace problems in C# which i have to have in mind


Re: XNA Framework C# Performance Problems

Nick Darnell

Exceptions are very slow. When they are thrown. However the try/catch construct adds very little overhead by its self, of course even a little overhead adds up if you're processing 100's every render pass. What did your code look like




Re: XNA Framework C# Performance Problems

malignate88

I used exceptions in a wrong way, but now it works.
btw: my code is a XNA Game Engine with more than 150 classes. I dont think you want to see all ;).

Are there some other problems or tipps to improve my C# performance




Re: XNA Framework C# Performance Problems

dczraptor

You could try profiling your code. Here's the .NET CLR Profiler: http://www.microsoft.com/downloads/details.aspx FamilyId=A362781C-3870-43BE-8926-862B40AA0CD0&displaylang=en

As a personal tip from when i used the profiler, don't create a dictionary with Keyboard Keys as the key for the dictionary:

Dictionary<Keys, bool>, and instead cast to an int - Dictionary<int, bool>






Re: XNA Framework C# Performance Problems

Shawn Hargreaves - MSFT

The .NET design guidelines are a good read for all C# developers. Not all about performance, but also includes lots of good stuff about style, naming, class structure and so on:

http://msdn.microsoft.com/library/default.asp url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

Video presentations about the same material:

http://msdn2.microsoft.com/en-us/netframework/aa497250.aspx

Rico's blog is also a good read, but I have to add a disclaimer that he's very focused on performance. Sometimes performance isn't the most important thing, and some of the things he talks about can make your code much harder to understand and maintain. So, read what he has to say, and apply it where you need to, but don't go totally overboard with all of this:

http://blogs.msdn.com/ricom/





Re: XNA Framework C# Performance Problems

Nick Darnell

Cache cache and more cache. Object creation is a fairly expensive (relatively speaking). So try not to create objects needlessly. When passing around structs use "ref" otherwise they will be passed by value. If some fields need to be accessed a lot but only by the classes in your assembly make them internal and let classes directly access them instead of through properties, because encapsulating them adds a small amount of needless overhead.




Re: XNA Framework C# Performance Problems

Fluxtah

If some fields need to be accessed a lot but only by the classes in your assembly make them internal and let classes directly access them instead of through properties, because encapsulating them adds a small amount of needless overhead.

I would like to know if this is really true, as I was thinking this also, after a small test of field access vs property access, I found field access about 3-4 times faster than property access.

However, I was reading about this, and read that properties that do nothing else but return a value, will get inlined when jitted.





Re: XNA Framework C# Performance Problems

Nick Darnell

You could always create a test project and decompile it with ILDASM and see what it shows. But for standard get/sets it's true. You have to remember a "property" really is nothing more than a method masquerading as something new. So for any access you have to push the property onto the stack to get the property, then inside the property the CLR has to push the field. (though i think i remember reading MS said to use properties if it should be one, if that's because they can optimize those...i do not know).

Though I doubt that to be true, because there's nothing different between a get and a set. True, normally you wouldn't think a getter would be doing something extra, but there is nothing stopping me from putting code inside the get portion of the property to do something else, so it can't simply inline the call to the field. It would have to inline everything. So why not set also






Re: XNA Framework C# Performance Problems

malignate88

Comparing my terrain with an Ogre Demo shows that my Demo is about 80% slower and i dont know why. I hava a special Scenegraph Design, which needs many object conversions during runime. Do you think this can affect the performance




Re: XNA Framework C# Performance Problems

Fluxtah

Reading more into this I found some articles and forum topics that suggest the properties that are of value types do not get inlined where object types do get inlined, wether this is true or not, I am not sure.

I come from a business application programming background where I use C# exclusively to build apps, and I would have never considered not using properties, but since using XNA I try to avoid using properties in my game engine, I just wonder if it is bad practice in XNA game development or indeed I will squeeze more performance out of .NET.





Re: XNA Framework C# Performance Problems

Leaf.

Method inlining is less likely to happen on the Xbox 360/Compact framework. So on that platform you might see an improvement if you reduce the number of method calls - reducing the use of properties will obviously reduce the use of methods since they are the same thing.

But it's important to keep in mind that this may only have a small positive effect on performance but a large negative effect on the stability, readability and maintenability of your code. I see far too many people on these forums blithely saying that they never use foreach or properties because they are slower, when really they should be considering where and if they actually need to make such micro optimizations. Foreach is a really nice language construct, I miss it when I have to program in C++. The only reason it is 'slower' is because when used to iterate over some container types it creates an enumerator object and sometimes you need to be careful of the numbers of objects you create. Note, foreach does not create enumerator objects when used with arrays.

If you have good programming habits from your day job then stick with them. Then when you have enough of a game to make useful profiles, profile your code. Use the profiles to see where you might need to optimize. Look for algorithmic optimizations first, then if you still can't get the performance you require you might want to consider using some of the optimizations that have been mentioned in this thread. Only use them where they will actually have an effect, if you have a property that you only access 20 times a frame there's very little point making it a public field.

Cheers,
Leaf.






Re: XNA Framework C# Performance Problems

Shawn Hargreaves - MSFT

Various clever people write about properties versus fields:

http://blogs.msdn.com/ricom/archive/2006/08/31/performance-quiz-11-ten-questions-on-value-based-programming.aspx
http://blogs.msdn.com/ericgu/archive/2007/02/01/properties-vs-public-fields-redux.aspx
http://blogs.msdn.com/ericgu/archive/2007/02/02/more-on-properties-vs-fields.aspx





Re: XNA Framework C# Performance Problems

malignate88

But i think its not the main reason, why my terrain demo is so slow. I used a profiler (Ants is the best piece of software i have had in my hands for 2 years ) and recognized, that this are the slowest things.

BoundingSphere, BoundingBox & BoundingSphere, especially Culling.
Accessing Paramters of Shaders.
Working with Dictionary-Container and Accessing them.
Keyboard.GetState()

Do some other have performance problems with C# or seems the performance to be okay, in comparison with native applications




Re: XNA Framework C# Performance Problems

Joel Martinez

Nick Darnell wrote:
... Cache cache and more cache. Object creation is a fairly expensive (relatively speaking) ...
Just to be clear ... object creation is not expensive at all. But the existence (and eventual collection) of the object is what's expensive. Particularly on the 360/CF. The reason you'd want to reuse object instances is to avoid triggering the garbage collector. :-)





Re: XNA Framework C# Performance Problems

malignate88

But I think that is nevertheless a very good suggestion - especially for Particle Systems.