Checking strings against length seem to have better perf

[Youssef1313]

Benchmark results on my machine:

|            Method |      Mean |     Error |    StdDev |    Median |
|------------------ |----------:|----------:|----------:|----------:|
|  CompareWithEmpty | 1.6891 ns | 0.0208 ns | 0.0195 ns | 1.6881 ns |
| CompareWithLength | 0.4947 ns | 0.2319 ns | 0.6837 ns | 0.0491 ns |

I'm not sure of the actual reason why checking Length == 0 would be faster than checking string == string.Empty. (If there is a known reason, I'd like to know about it)

[Youssef1313]

@EgorBo Thanks for review. How to know that it's optimized to just return false; ?
I checked SharpLab in Release mode and I don't see a direct return false there. Is this approach incorrect?

[Youssef1313]

I've changed the benchmark code to the following:

using System;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

namespace MyBenchmarks
{
    public class EmptyStringBenchmarks
    {

        private bool InternalCompareWithEmpty(string s)
        {
            return s == String.Empty;
        }
    
        private bool InternalCompareWithLength(string s)
        {
            return s.Length == 0;
        }

        [Benchmark]
        public bool CompareWithEmpty()
        {
			bool result = false;
			string[] arr = new string[] {"test", ""};
			foreach (string s in arr)
				result = InternalCompareWithEmpty(s);
			return result;
        }

        [Benchmark]
        public bool CompareWithLength()
        {
			bool result = false;
			string[] arr = new string[] {"test", ""};
			foreach (string s in arr)
				result = InternalCompareWithLength(s);
			return result;
       }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            var summary = BenchmarkRunner.Run<EmptyStringBenchmarks>();
        }
    }
}

And got the following result:

|                 Method |     Mean |    Error |   StdDev |   Median |
|----------------------- |---------:|---------:|---------:|---------:|
|       CompareWithEmpty | 17.73 ns | 2.355 ns | 6.944 ns | 13.81 ns |
|      CompareWithLength | 13.82 ns | 1.905 ns | 5.618 ns | 11.82 ns |

So, it will seems that Length is faster?
@EgorBo

[Youssef1313]

I just knew about Parameterization in BenchmarkDotNet.

Is a code like the following will give accurate and correct results?

using System;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

namespace MyBenchmarks
{
    public class EmptyStringBenchmarks
    {
        [Params("test", "")]
        public string MyStr { get; set; }
        
        [Benchmark]
        public bool CompareWithEmpty()
        {
            return MyStr == string.Empty;
        }

        [Benchmark]
        public bool CompareWithLength()
        {
            return MyStr.Length == 0;
       }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            var summary = BenchmarkRunner.Run<EmptyStringBenchmarks>();
        }
    }
}

[huoyaoyuan]

Is a code like the following will give accurate and correct results?

I'm also adding IsNullOrEmpty to comparison:

Method	MyStr	Mean	Error	StdDev
CompareWithEmpty		0.7202 ns	0.0181 ns	0.0170 ns
CompareWithLength		0.0000 ns	0.0000 ns	0.0000 ns
IsNullOrEmpty		0.2096 ns	0.0021 ns	0.0018 ns
CompareWithEmpty	test	1.2279 ns	0.0086 ns	0.0081 ns
CompareWithLength	test	0.0000 ns	0.0000 ns	0.0000 ns
IsNullOrEmpty	test	0.2975 ns	0.0027 ns	0.0022 ns

seems that .Length == 0 is inlined by JIT.

[huoyaoyuan]

public string MyStr { [MethodImpl(MethodImplOptions.NoInlining)]get; set; }

Adding NoInlining gets measurable result:

Method	MyStr	Mean	Error	StdDev
CompareWithEmpty		1.9470 ns	0.0042 ns	0.0039 ns
CompareWithLength		0.9114 ns	0.0048 ns	0.0040 ns
IsNullOrEmpty		1.3153 ns	0.0105 ns	0.0093 ns
CompareWithEmpty	test	2.3725 ns	0.0158 ns	0.0147 ns
CompareWithLength	test	0.9059 ns	0.0026 ns	0.0022 ns
IsNullOrEmpty	test	1.4731 ns	0.0152 ns	0.0142 ns

[Youssef1313]

@huoyaoyuan Yes. Seeing 0.0000ns indicates JIT optimization. However, it still seems that .Length == 0 will be faster without JIT optimization.

Because IsNullOrEmpty internally checks the Length and not comparing to string.Empty.
And IsNullOrEmpty seems that it's not getting optimized and faster than comparing to string.Empty.

But I still don't know how to make a correct benchmarking without annoying JIT optimizations

[Youssef1313]

@huoyaoyuan , Thanks for the NoInlining tip!
So, the results you posted should be correct now and indicates that .Length == 0 is faster :)

[benaadams]

.Length == 0 and .IsNullOrEmpty will both get inlined; == string.Empty calls string.Equals which is chunky and will not get inlined

[Youssef1313]

.Length == 0 and .IsNullOrEmpty will both get inlined; == string.Empty calls string.Equals which is chunky and will not get inlined

Did you check the results by @huoyaoyuan where he disabled inlining?

[benaadams]

== Empty will have at least 3 checks when its not equal

runtime/src/libraries/System.Private.CoreLib/src/System/String.Comparison.cs

Lines 598 to 611 in 0c39507

	public bool Equals(string? value)
	{
	if (object.ReferenceEquals(this, value))
	return true;
	// NOTE: No need to worry about casting to object here.
	// If either side of an == comparison between strings
	// is null, Roslyn generates a simple ceq instruction
	// instead of calling string.op_Equality.
	if (value == null)
	return false;
	if (this.Length != value.Length)
	return false;

ReferenceEquals, == null, Length != value.Length

[Youssef1313]

@benadams, So, that's the reason of it being slower right?

If my changes are correct, please notify me to take care of the current build errors.