To check or not to check (to Nothing(null))?

From the performance view, is it better to check or not to check for Nothing(null) before set it?

Is clear that for readability maybe there is no need of supplementary step, but for performance? Maybe testing the IF is less time consuming that setting to NULL, if there is no need of?!

I run that on a computer, and the result was the same.

  Dim sw As Ne开发者_StackOverfloww Stopwatch()

  sw.Start()
  For i As Integer = 0 To 10000
    _MyObject = Nothing
  Next

  sw.Stop()
  Console.WriteLine("no check: {0}", sw.Elapsed)
  sw.Reset()

  sw.Start()
  For i As Integer = 0 To 10000
    If _MyObject IsNot Nothing Then
      _MyObject = Nothing
    End If
  Next

  sw.Stop()
  Console.WriteLine("with check: {0}", sw.Elapsed)

Result:

no check: 00:00:00.0000326

with check: 00:00:00.0000349

There really is no logical reason to check if the value is already null/Nothing. As you can see you take a small hit in performance with the check anyway.

The reason your stopwatch times come out to be the same is because you're not resetting the stopwatch in between rounds. StartNew() won't work. The sw.Elapsed from your second run is reporting the same time as your first run.

Replace sw.StartNew() with a restart:

sw.Restart()

When I run it on my machine, I get .248 and .592 respectively.

Adding If statements is always slower from a performance perspective. But, from a best practices standpoint, you should always check to see if an object is null before using it.

  If _MyCustomObject IsNot Nothing Then
      _MyCustomObject = Nothing

My guess is that there is really no difference between the two. If there is one, it will be negligible (micro-optimization). (And like I said in my comment the if statement is most likely slower). And this one is more verbose. You don't care if it is nothing, you just need it to be nothing when you're done. You're adding an extra step where you don't need it. Less code to read normally means it's clearer to the reader and that = better in my book.

There will be times you want to check before setting a value. Say if you have to retrieve the value from a database, but this most likely isn't one of them.

Generally speaking, on modern CPUs it's better to always do some small operation than to check and then do it only if it's necessary. This is because the branch instruction can break the pipeline in the CPU, causing a significant (several cycles) delay. If you always do the small operation, not only is there no time spent doing a comparison, there is also no chance of stalling the pipeline.

In other words, there's almost no way that checking is going to make things faster, and could possibly slow things down. Odds are that the JIT optimizer removes the If anyway, though.

If you need to set it to null, then just set it. The code is more readable that way.

Having an extra if might have perf implications too, but the compiler might be smart enough to optmize it out, so your tests might not be able to tell the difference.

So just setting it to null has two upsides

• Readability (the more important one)
• Possibly better perf because of the missing if.

A possible upside for doing the not-null check is that .net engine might run some extra code about objects going out of scope when you set stuff to null. I don't think that is good enough reason for sacrificing readability, though.

I wouldn't be surprised the compiler removes the if test and generates the exact same IL for both. But you could run ilasm on your resulting assembly to know for sure.