There's a few ways to do this. Often, in the framework (if you look at source code through Reflector), you'll see a cast of the instance of the type parameter to object and then checking that against null, like so:
if (((object) instance) == null)
throw new ArgumentNullException("instance");
And for the most part, this is fine. However, there's a problem.
Consider the five main cases where an unconstrained instance of T could be checked against null:
- An instance of a value type that is not
Nullable<T>
- An instance of a value type that is
Nullable<T> but is not null
- An instance of a value type that is
Nullable<T> but is null
- An instance of a reference type that is not
null
- An instance of a reference type that is
null
In most of these cases, the performance is fine, but in the cases where you are comparing against Nullable<T>, there's a severe performance hit, more than an order of magnitude in one case and at least five times as much in the other case.
First, let's define the method:
static bool IsNullCast<T>(T instance)
{
return ((object) instance == null);
}
As well as the test harness method:
private const int Iterations = 100000000;
static void Test(Action a)
{
// Start the stopwatch.
Stopwatch s = Stopwatch.StartNew();
// Loop
for (int i = 0; i < Iterations; ++i)
{
// Perform the action.
a();
}
// Write the time.
Console.WriteLine("Time: {0} ms", s.ElapsedMilliseconds);
// Collect garbage to not interfere with other tests.
GC.Collect();
}
Something should be said about the fact that it takes ten million iterations to point this out.
There's definitely an argument that it doesn't matter, and normally, I'd agree. However, I found this over the course of iterating over a very large set of data in a tight loop (building decision trees for tens of thousands of items with hundreds of attributes each) and it was a definite factor.
That said, here are the tests against the casting method:
Console.WriteLine("Value type");
Test(() => IsNullCast(1));
Console.WriteLine();
Console.WriteLine("Non-null nullable value type");
Test(() => IsNullCast((int?)1));
Console.WriteLine();
Console.WriteLine("Null nullable value type");
Test(() => IsNullCast((int?)null));
Console.WriteLine();
// The object.
var o = new object();
Console.WriteLine("Not null reference type.");
Test(() => IsNullCast(o));
Console.WriteLine();
// Set to null.
o = null;
Console.WriteLine("Not null reference type.");
Test(() => IsNullCast<object>(null));
Console.WriteLine();
This outputs:
Value type
Time: 1171 ms
Non-null nullable value type
Time: 18779 ms
Null nullable value type
Time: 9757 ms
Not null reference type.
Time: 812 ms
Null reference type.
Time: 849 ms
Note in the case of a non-null Nullable<T> as well as a null Nullable<T>; the first is over fifteen times slower than checking against a value type that is not Nullable<T> while the second is at least eight times as slow.
The reason for this is boxing. For every instance of Nullable<T> that is passed in, when casting to object for a comparison, the value type has to be boxed, which means an allocation on the heap, etc.
This can be improved upon, however, by compiling code on the fly. A helper class can be defined which will provide the implementation of a call to IsNull, assigned on the fly when the type is created, like so:
static class IsNullHelper<T>
{
private static Predicate<T> CreatePredicate()
{
// If the default is not null, then
// set to false.
if (((object) default(T)) != null) return t => false;
// Create the expression that checks and return.
ParameterExpression p = Expression.Parameter(typeof (T), "t");
// Compare to null.
BinaryExpression equals = Expression.Equal(p,
Expression.Constant(null, typeof(T)));
// Create the lambda and return.
return Expression.Lambda<Predicate<T>>(equals, p).Compile();
}
internal static readonly Predicate<T> IsNull = CreatePredicate();
}
A few things to note:
- We're actually using the same trick of casting the instance of the result of
default(T) to object in order to see if the type can have null assigned to it. It's ok to do here, because it's only being called once per type that this is being called for.
- If the default value for
T is not null, then it's assumed null cannot be assigned to an instance of T. In this case, there's no reason to actually generate a lambda using the Expression class, as the condition is always false.
- If the type can have
null assigned to it, then it's easy enough to create a lambda expression which compares against null and then compile it on-the-fly.
Now, running this test:
Console.WriteLine("Value type");
Test(() => IsNullHelper<int>.IsNull(1));
Console.WriteLine();
Console.WriteLine("Non-null nullable value type");
Test(() => IsNullHelper<int?>.IsNull(1));
Console.WriteLine();
Console.WriteLine("Null nullable value type");
Test(() => IsNullHelper<int?>.IsNull(null));
Console.WriteLine();
// The object.
var o = new object();
Console.WriteLine("Not null reference type.");
Test(() => IsNullHelper<object>.IsNull(o));
Console.WriteLine();
Console.WriteLine("Null reference type.");
Test(() => IsNullHelper<object>.IsNull(null));
Console.WriteLine();
The output is:
Value type
Time: 959 ms
Non-null nullable value type
Time: 1365 ms
Null nullable value type
Time: 788 ms
Not null reference type.
Time: 604 ms
Null reference type.
Time: 646 ms
These numbers are much better in the two cases above, and overall better (although negligible) in the others. There's no boxing, and the Nullable<T> is copied onto the stack, which is a much faster operation than creating a new object on the heap (which the prior test was doing).
One could go further and use Reflection Emit to generate an interface implementation on the fly, but I've found the results to be negligible, if not worse than using a compiled lambda. The code is also more difficult to maintain, as you have to create new builders for the type, as well as possibly an assembly and module.
