4

I attended a seminar a few months ago and the speaker made the statement that the general cost of a boxing or unboxing operation has been reduced since .NET 1.1. I've looked through my (poor) notes and can't determine if this statement makes reference to the box and unbox instructions, or to the introduction of classes (i.e. generic types) that make boxing/unboxing less likely to occur.

Has there been a performance improvement in the CLR boxing-related instructions between .NET 1.1 and .NET 4.0, and if so, where can I find information on the measurements that show the gains?

Steve Guidi
  • 19,700
  • 9
  • 74
  • 90
  • 1
    It is rather the opposite, un/boxing was *highly* optimized in .NET 1.0. The additions of Nullable and generics made it unboxing more involved, requiring CLR helper methods. It was drastically reducing the number of boxings with generics that made all the difference. http://stackoverflow.com/questions/1583050/performance-surprise-with-as-and-nullable-types/3076525#3076525 – Hans Passant Oct 13 '11 at 23:29

2 Answers2

6

I can't comment on the performance (for that you'd need profiling, etc) - but one interesting change here is the constrained op-code, that is used in particular with generics. The advantage here is that for a method like:

static void DoSomething<T>(T x, T y) where T : IComparable<T>
{
    if(x.CompareTo(y) < 0) { /* whatever */ }
}

it will use a constrained-call for CompareTo, which allows it to either use a static-call to the method implementation on a value-type (without an unbox), or use a virtual-call if it is a reference-type. Normally, calling an interface-based method on a value-type requires a box, so this is pretty helpful.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Is there any way to do something similar if one is given a generic type parameter that may or may not implement some interface (e.g. IDisposable)? At least in vb.net, the only way I can think of to conditionally use an interface function on a generic type parameter would be to cast to object and then try casting that to the interface, but that would end up boxing the item whether or not the cast to the interface would even work. Nasty. – supercat Oct 14 '11 at 00:34
  • @supercat no, at that point you'd have to `as` to the interface and hence box – Marc Gravell Oct 14 '11 at 05:09
  • I didn't know of any way to get around that, but was wondering if there might be. I wonder if the CLR could support such an "if-constraint" construct: If a generic type meets a certain constraint, run some code that would require it to meet that constraint. Since a separate copy of a generic routine will be compiled for every combination of generic value types used therein, it would seem theoretically possible. Otherwise, is it possible to write something analogous to "Comparer.Default" without reflection? – supercat Oct 14 '11 at 14:32
1

Boxing and unboxing should be avoided as much as possible. From MSDN:

It is best to avoid using value types in situations where they must be boxed a high number of times, for example in non-generic collections classes such as System.Collections::ArrayList. You can avoid boxing of value types by using generic collections such as System.Collections.Generic::List. Boxing and unboxing are computationally expensive processes. When a value type is boxed, an entirely new object must be created. This can take up to 20 times longer than a simple reference assignment. When unboxing, the casting process can take four times as long as an assignment.

MS have done what they can to minimize the cost of boxing operations themselves, but there's only so much that can be done.

MUCH better performance improvement can be achieved by eliminating as much boxing as possible from one's code. Avoiding non-generic containers is a VERY effective way of massively reducing boxing. Being able to use generic containers is one of the primary benefits of moving from NETFX 1.1 to 2.0+.

Rich Turner
  • 10,800
  • 1
  • 51
  • 68