Probably subjective - but a null check is equivalent an equal-to-zero check, and just as quick. So I don't think you should be worrying about this.
Equally - unless you have performance problems why bother playing with it.
Also equally, if you do have performance problems, it's most likely that you'll be able to garner performance from complex branches of code rather than eliminating a few null checks.
That said, for conditional code, a potential performance improvement (however it would seriously need to be benchmarked) might be to use delegates for the different branches of logic that are set as the result of one or more conditions changes - but I'd be surprised if such a solution actually improves performance in the general case - especially for your 'is null' scenario. So, by that I mean something like this:
if([condition])
{
Foo();
}
else
{
Bar();
}
If, say, [condition]
involves a local variable _obj
(in your case _obj == null
) - you can replace with something like this (but be very very wary of threading issues):
private Action _logic;
private object _obj;
public Object Obj {
get { return Obj; }
set {
_obj=value;
if([condition])
_logic = () => Foo();
else
_logic = () => Bar();
}
}
And now in any code where you previously have checked [condition]
to do the branching you now simply do:
_logic();
This kind of thing gains most improvements when the [condition]
is complex and, crucially, has been proven to be taking up a lot of processor time through profiling. Using delegates will also carry a slight overhead over the conditional branching, but if that overhead is less then the execution of the [condition]
then it can make a difference, especially if those checks are being performed very frequently.
There are other variations of this too, most commonly function lookup tables derived from a value instead of choosing a branch of code based on an equality check (which is how large switch/case statements can be implemented - delegates added to a Dictionary
keyed by the enum/value being checked - which avoids multiple checks of the value).
Ultimately, though, without the due-diligence of profiling (before and after, of course), carrying out such optimisations is fundamentally pointless.