Also smells of NullReferenceException. Did you check all the places you updated guarantee the string is non-null?

@miloush, Yes I checked that. But it's better to double check in case I missed something.

@miloush I checked all too.

Thank you @Youssef1313 and it looks good for me.

Short question:
Is value.Length != 0 faster than value.Length > 0?

Short question:
Is value.Length != 0 faster than value.Length > 0?

I think both of these are very fast. Sorry, I can't answer your question directly.

@lindexi
I wrote a little benchmark in LinqPad:

const int Iterations = 10000000;

void Main()
{
	BenchNotEqual();
	BenchGreaterThan();
}

void BenchNotEqual() {
	var list = new List<bool>();
	var watch = new Stopwatch();
	watch.Start();
	
	for(var i = 0; i < Iterations; i++) {
		list.Add(RunNotEqual(i));
	}
	watch.Stop();

	Console.WriteLine($"Not equal took: {watch.ElapsedMilliseconds}ms");
}

void BenchGreaterThan()
{
	var list = new List<bool>();
	var watch = new Stopwatch();
	watch.Start();


	for (var i = 0; i < Iterations; i++)
	{
		list.Add(RunGreaterThan(i));
	}
	watch.Stop();

	Console.WriteLine($"Greater than took: {watch.ElapsedMilliseconds}ms");
}

[MethodImplAttribute(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
bool RunNotEqual(int number) {
	return number != 0;
}

[MethodImplAttribute(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
bool RunGreaterThan(int number)
{
	return number > 0;
}

I ran this script about 10 times and greater than was faster.

Not equal took: 156ms
Greater than took: 132ms

Feel free to try, maybe the results are not the same everywhere.

@deeprobin Sorry, I do not think your benchmark is correct.

The easiest way to check which is fastest is to check the generated native code from the JIT. In my example I'll use x86 for simplicity. Both checks generate almost the same native code with the exception of the instruction for the comparison (setne for != and setg for >). So it's just the difference of both of these instruction. I think it is fair to say that both instruction are pretty close to each other because if they weren't, someone would probably already have modified the JIT to use the fastest. Also, given the speed of modern processor, I wouldn't bother comparing two of these similar instruction because the difference is likely to small to be even measurable (Probably not 156 ms vs 132 ms).

I would also recommend using BenchmarkDotNet to do micro-benchmark like this, instead of using LinqPad because the actual code that you want to compare gets watered down by other code that are way slower which ends up corrupting your results.

Use sharplab.io to check native code:
https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3utmbjgEYD21ANtgHLXACiAjgK5h0AUcSAAzYAbj04BTAJSlyJNOUW4A7KPESAdABkJAOwDmwABbYAhAF5sggNyyyAXzvYnWbDXrYA4gCcJYYBLeACpGYLr8Qmp0kjIKck6KcKpi0Zo6BsbYAHxWtnEO6PZAA==

@RussKie can we get this merged? Thanks!

@RussKie Do you know who can give a second review and merge?

@Youssef1313 This is under review by @dotnet/wpf-developers

@Youssef1313 , thank you for your contribution.