Does string.IsNullOrEmpty have performance issues?

Question

Is there any difference between this two ways of checking the string?

if(!string.IsNullOrEmpty(myString))
{
  //Do something
}

and

if(myString != null && myString != "")
{
  //Do something
}

So far I though no, but someone is saying so. And he's saying that the second one is better as the first one requires a method call.

I'm a little confused.

Answer 1

No, there are no performance problems with it. Here's how it is implemented:

public static bool IsNullOrEmpty(string value)
{
    if (value != null)
    {
        return (value.Length == 0);
    }
    return true;
}

I would use always use IsNullOrEmpty instead of writing the 2 conditions manually. It's much more readable and there is no performance cost associated to using it.

Answer 2

Like every one else who answered, I assumed there would be no performance difference, but I ran a benchmark just to be sure. The results are not exactly what I expected...

Here's the code for my benchmark:

using System;
using System.Diagnostics;

static class Program
{
    static void Main()
    {
        int count = 1;

        // First run for JIT warm-up
        IsNullOrEmpty(null, count);
        TestEqualsEmpty(null, count);
        TestLengthZero(null, count);

        count = 1000000000;

        Console.WriteLine("Case 1: s == \"test\"");
        RunTests("test", count);

        Console.WriteLine("Case 2: s == null");
        RunTests(null, count);

        Console.WriteLine("Case 3: s == \"\"");
        RunTests("", count);
    }

    static void RunTests(string s, int count)
    {
        var ts = IsNullOrEmpty(s, count);
        Console.WriteLine("\tIsNullOrEmpty:         {0}", ts);

        ts = TestLengthZero(s, count);
        Console.WriteLine("\tTest if s.Length == 0: {0}", ts);

        ts = TestEqualsEmpty(s, count);
        Console.WriteLine("\tTest if s == \"\":       {0}", ts);
    }

    static TimeSpan IsNullOrEmpty(string s, int count)
    {
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < count; i++)
        {
            if (string.IsNullOrEmpty(s))
            {
            }
        }
        sw.Stop();
        return sw.Elapsed;
    }

    static TimeSpan TestLengthZero(string s, int count)
    {
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < count; i++)
        {
            if (s == null || s.Length == 0)
            {
            }
        }
        sw.Stop();
        return sw.Elapsed;
    }

    static TimeSpan TestEqualsEmpty(string s, int count)
    {
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < count; i++)
        {
            if (s == null || s == "")
            {
            }
        }
        sw.Stop();
        return sw.Elapsed;
    }
}

And here are the results:

Case 1: s == "test"
        IsNullOrEmpty:         00:00:00.6000748
        Test if s.Length == 0: 00:00:00.5566793
        Test if s == "":       00:00:02.2284007
Case 2: s == null
        IsNullOrEmpty:         00:00:00.5556170
        Test if s.Length == 0: 00:00:00.5569102
        Test if s == "":       00:00:00.5554338
Case 3: s == ""
        IsNullOrEmpty:         00:00:00.5568344
        Test if s.Length == 0: 00:00:00.5556285
        Test if s == "":       00:00:03.0626445

(compiled with optimisations enabled; these are the results with the 32-bit CLR, but the results are similar for the 64-bit CLR)

So as you can see, if the string is not null, calling IsNullOrEmpty is much faster than comparing with null and "", and almost as fast as comparing with null and testing if the length is 0. If the string is null, all 3 methods have identical performance.

So, doing this:

if(myString != null && myString != "")

is probably going to be slower, not faster, than this:

if(string.IsNullOrEmpty(myString))

You could do this:

if(myString != null && myString.Length > 0)

but the performance gain would be very small compared to calling IsNullOrEmpty, and it would harm readability.

Note that this benchmark was run with 1,000,000,000 (1 billion) iterations; this was necessary to notice an actual difference. In a real-world scenario, the difference would probably be to small to notice; this is clearly a micro-optimisation.