Optimizing Performance On The Xbox 360 - Part 2

In part 1 I described the reasons why Xbox 360 is slower than an equivalent PC and  some of the basic recommendations for optimizing C# code to make it run faster. In this post I will mention a few other tricks to increase performance on the Xbox 360.

Structures… again.

In the .NET world, objects are allocated on the heap and structures are allocated on the stack. Remember, only the heap is garbage collected, this means that structures are not subject to the expensive garbage collection operation. Allocation on the stack is basically free as we only need to increase a stack pointer and call a constructor. This means you can reduce garbage collection and increase speed by using structures instead of objects – however, you need to know the difference between the two. You should also follow the general recommendations for using structures:

  • Small data objects (data containers)
  • Often destroyed or created
  • Read-only (or mostly-read) objects

Reuse those objects

As mentioned before, objects are allocated on the heap that is garbage collected. That is why you should avoid creating a lot of objects on each update. Instead, you should reuse the objects using pools as explained in part 1. Another and simpler way is to move the object to outer scope and/or make it static. One object that you should pay close attention to is the SpriteBatch (if you are using XNA). Do not create the SpriteBatch object on each update, but keep a reference to it through out the game.

You should also pay attention to List<T>, arrays and other commonly used list types. When you create a new List<T> and add a single item to it, it will initialize an array with a size of 4. If you add more than 4 elements, it will create a new array with double the size. The results is that 2 arrays have been garbage collected. To keep that from happening, you should initialize List<T> with a capacity that is equal to what you need. To keep the List<T> form being garbage collected, you should move the list to outer scope and clear it before use instead of initializing a new instance.

Boxing

Boxing is the process of encapsulating a value type in a reference type container. This is great as it allows us to pass value types as objects to methods or store them in collections as objects. However, this is not great for performance and we have to eliminate boxing and unboxing where we can. You can use tools like Reflector or Ildasm to disassemble your application to MSIL code. Inside the MSIL code you simply look for the box and unbox keywords. You can find more info along with pictures in my post Performance Tips and Tricks Part 4.

Further reading

I recommend you read two GDC 2008 PowerPoint presentations. CLR Performance by Frank Savage and Understanding XNA Framework Performance by Shawn Hargreaves.

Comments

Post a Comment

Popular posts from this blog

.NET Compression Libraries Benchmark

Image
I often find myself needing a compression library in a software development project, and after a few tests with disappointing results I usually fall back to spawning 7Zip as an external process. This time however, the application specification prohibits any data written to disk, which 7Zip needs to do in order to work correctly. I needed to do everything in memory, and so I had to test some of the C# libraries available for compression as well as the different compression algorithms. Here is a full list of the tested libraries: .NET DeflateStream ICSharpCode SharpZip Zlib.NET DotNetZip Managed LZMA LZMA SDK QuickLZ    Compression 101 Before I get to the results of the benchmark, I think it is important to understand the different archive formats and compression algorithms in order to compare the results with other benchmarks/and or tests. Lets get to it! A compression algorithm can be compared to a small machine that takes in some data, do some math on it and transfor
Read more

Reducing the size of self-contained .NET Core applications

Just for note keeping, I've written down some methods of reducing the size of a .NET Core application. I thought others could use it as well, so here you go. Original Size First off, let's see how much disk space a self-contained 'hello world' application takes up. > dotnet new console > dotnet publish -r win-x86 -c release Size: 53.9 MB -  yuck! Trimming Microsoft has built a tool that finds unused assemblies and removes them from the distribution package. This is much needed since the 'netcoreapp2.0' profile is basically .NET Framework all over again, and it contains a truckload of assemblies our little 'hello world' application don't use. > dotnet new console > dotnet add package Microsoft.Packaging.Tools.Trimming -v 1.1.0-preview1-25818-01 > dotnet publish -r win-x86 -c release /p:TrimUnusedDependencies=true Size: 15.8 MB Much better! Although, we have only removed unused assemblies - what about unused
Read more

Convex polygon based collision detection

Image
A lot of people have asked me: Why use a convex polygon only engine like Box2D? In this post I will provide some info on why convex polygons is the optimal polygon type to use. What does convex mean? Convex polygons needs to satisfy the following requirements: All internal angles must be below 180 degrees Every line segment between two vertices can be contained fully inside or at the edge the polygon A non-convex polygon is called a concave polygon and it must have an internal angle measuring greater than 180 degrees. As you might have thought about yourself; concave polygons can be quite handy. Convex-only engines can’t represent a simple player polygon like Pac-Man . Why use convex-only? There are really only one big juicy reason: performance Physics engines are able to take quite a few shortcuts and use cheap algorithms to determine the closest vertex, shortest distance and a lot more. An algorithm like Separating Axis Theorem and the Gilbert – Johnson –
Read more