This post originated from an RSS feed registered with .NET Buzz
by David Cumps.
Original Post: Boxing/Unboxing
Feed Title: David Cumps
Feed URL: http://weblogs.asp.net/cumpsd/rss?containerid=12
Feed Description: A Student .Net Blog :p
In the .NET Framework there is a feature called boxing, which goes hand in hand with unboxing. Boxing is an implicit conversion of a value-type to the object type.
While this is a very nice feature when programming normal applications, this overhead becomes a big performance hit when working with algorithms that need to do lots of operations, such as pathfinding.
When you create a value-type, itâs originally placed on the stack. If you box this value-type, the required memory is allocated on the heap, the value gets copied and an object is placed on the stack, pointing to the boxed value on the heap
In the pathfinder, explained above, a list of points had to be maintained. While this was possible using an ArrayList, it proved faster to write a typed list. The main reason behind this was because the ArrayListâs method signatures all work with objects, causing implicit boxing when using them. Retrieving items from an ArrayList also required unboxing, because that had to be cast back into their Point type.
I wrote a small application to demonstrate the boxing and unboxing taking place, and the performance impact. The test data were 10 million random Point values.
// Adding to an ArrayList
for (int i = 0; i < itemsToGenerate; i++) {
arrayList.Add(rndCosts[i]);
}
When we take a look at the IL code this piece generates, we would see the following:
On the second line, you can see it uses the box operation to box our value-type Point (stored in the typed Point array rndCosts) before calling the Add method.
The solution to this is using generics, coming in .NET 2.0, or writing your own typed list object. As .NET 1.1 had to be used, the second solution was chosen. To do this, Reflector was used to look at the ArrayList code, and use that code to create a new list, replacing all instances of object with our required type, Point in this example.
It was required to do it this way, instead of just implementing the IList interface and only making the method signatures typed, while casting them to object in the methods anyway.
Now we use the same piece of test code with our PointList.
// Adding to a typed PointList
for (int i = 0; i < itemsToGenerate; i++) {
pointList.Add(rndCosts[i]);
}
If we look at the IL this piece generates, we notice the following:
The Framework does not use the box operation anymore, effectively getting rid of the overhead we had with our first solution. When we take a look at the test results, we can clearly see the difference between the first solution and the second.
ArrayList: added 10000000 items.
00:00:03.1845792
PointList: added 10000000 items.
00:00:00.2804032
By using the strong typed PointList it was possible to get just a bit more performance out of the code, making the project operate better in the long run.
Previous Topic
