Better performance compared to strings

First, you should not use Strings.len , this is something to use in the compatibility library with Visual Basic and, although possible, should not be used in new code, especially in C #. Not that it's problematic, just that it keeps using something that is not the standard. Use:

var text = "ola mundo";
WriteLine(text.Length > 0);
WriteLine(text != "");

The difference should be small. Both access a very basic data. Some people may think there will be a count of how many characters the text has, but this information is available and does not need to be calculated.

The second option can be optimized. It may be that the simple comparison of references already indicates that it is the same and does not have to do anything else (I do not think that is the case in this example, but I understand that this example is not quite what you want to know, it was used just to simplify).

It may be that the hash code comparison of the string already indicates that it is different, of course if it has to calculate the hash it may cost expensive, so I have doubts if he would do this.

Even worse case when comparing the first character will already identify whether it is equal or not. Since one side only has one character, the terminator, you do not need to check anything else. I'm hypothetically speaking, that's not how it works in practice.

In fact, we can look at the source code of the function that discovers the equality between two strings and see that it does the same as option 1 (done properly):

public static bool Equals(String a, String b) {
    if ((Object)a==(Object)b) return true;
    if ((Object)a==null || (Object)b==null) return false;
    if (a.Length != b.Length) return false;
    return EqualsHelper(a, b);
}

You can see that there are 2 or 3 branches (gross comparisons) before checking if the sizes are the same, this is an extra cost. Even in size checking you have to take the size of the two strings and not just one as in option 1. It is worse if you use a non-standard comparison.

Note that these issues are implementation details, so what counts today may not be valid tomorrow and depends very much on the exact situation.

Although it can not be said, it seems clear that option 1 is faster. This may change or may have some optimization that eliminates the excess code from option 2, but in practice we know this will not happen.

You do not need to look at the generated bytecode because it is not always an indication of the actual performance, unless it is identical, which in this case has no chance of being. >

If you want to know the exact difference you have to measure, if you just want the fastest is the information. It can be useful because if your routine is used in a large loop it can make a good difference in performance.

Neither option allocates memory, so it makes no difference.

I do not think this should be the kind of thing someone who is writing olá mundo should care about.

If you really want to know which is better or worse, ideally you look directly at the generated assembly. Remember to put it in the Release profile, otherwise you will not have the optimizations.

Another idea is to use profiling tools.