Tiny C# shortcut

Reading about validation on Brian Noyes' Data Binding with Windows Forms 2.0, I found this funny way of checking for a string not being empty or null:

!string.IsNullOrEmpty(name)

Yours truly usually does it this way:

name != null && name != ""

This is the kind of small, almost useless details that intrigue me, so I immediately created a micro-benchmark (I know, I know, "beware of micro-benchmarks") and found out that Brian's method is almost twice as fast as mine. I used Lutz Roeder's Reflector to try to find out why but it didn't shed any light, then I checked the generated code with Ildasm and indeed the code for option 0 seems slightly simpler, so from now on I'll be using string.IsNullOrEmpty() because, as an aside, I'll impress some people with my "deep" knowledge of the BCL.

10 Comments

  • Edgar, that's sweet! I do it the way you usually do. Brian's approach is MUCH more elegant.

  • You should not compare with an empty string but do this on length.



    name != null && name.Length!=0

  • Yes...string.IsNullOrEmpty() was introduced in V2 of the framework.



    Note that this did not exist in V1 or V1.1

  • Ramon,



    I disagree. I remember in the VB 6 days it was recommended to compare the length, but why not use String.IsNullOrEmpty? That's why it's there.



    Let me know if I'm wrong.

  • name != "" is bad because you're creating a string instance that then needs to be garbage created eventually.

  • I agree that string.IsNullOrEmpty is better and more elegant, I used it extensively even I haven't compare the 'internal difference' between these two methods (because I'd saved my typing time already) :o)



    If comparison is available, I'd like to see what's the diference of String.IsNullOrEmpty and string.IsNullOrEmpty internally instead. :P That's a pretty common FAQ in various NGs.

  • To answer your question why it is faster, though i do not know if this is correct, i would guess that it has to do with branch prediction used by processors as well as how the compiler compiles that statement. this meaning that you have 2 conditions with the statement, rather than 1 condition with isNullOrEmpty.



    also, using the comparison to "", does that create an empty string class object? it would be interesting to see if the following gave better performance.



    name != null && name.Length == 0



    -darren

  • er, name.Length != 0, just noticed ramon's post, so he was thinking the same thing.

  • I agree that comparing using...



    x == "";



    will create a new string instance, but in my comparisons I have been using the following since .Net was released...



    x == String.Empty;



    I would think performance would be the same or better with this approach over...



    x.Length == 0;



    although I haven't done any testing.

  • I'd have to say that any minor performance benefits of IsNullOrEmpty are second to the enhanced readability. Personally I think the descriptive method name is better than two "!="s and a "&&" :)

Comments have been disabled for this content.