Comment Feed for Why doesn't the C# compiler turn "" into string.Empty? (TechOff on Channel 9)

Re: Re: Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

evildictaitor — Thu, 08 Jan 2009 11:10:33 GMT

It makes no difference. Even on an x64 it's faster to do compare 32bits at a time because the processor can automatically redirect 32bit check loops through SSE and SSE2 instructions which are substantially faster.

@CannotResolveSymbol: It's handwritten, but it's been handwritten by someone who knows what they're doing.

The first check gets rid of the easy cases (length difference) and the method assumes that the arguments are non-null. It then has to fix both strings to get a char* for them and then search through them. It then notices rather cleverly that processors will stream the instructions, so it blocks them in 10 comparisons at once in the first loop (avoiding IP jumps which breaks streaming) and then goes through the remaining elements one by one in the second while loop.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Dexter — Thu, 08 Jan 2009 08:29:31 GMT

You can see the original source in SSCLI, it's the same. Even without the source you can conclude that it was written by a human, the C# compiler doesn't perform such kind of optimizations.

Re: Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

JonathonW — Thu, 08 Jan 2009 01:46:49 GMT

Because 32-bit systems natively do integer operations with 32-bit integers, perhaps? What do you get if you compile as 64-bit (or look at the 64-bit version of the runtime)?

I'd also be interested in seeing the actual (original, non-compiled) source to EqualsHelper()... was that code entirely written by a human or is the compiler doing some degree of loop unrolling there?

Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Minh — Thu, 08 Jan 2009 00:55:44 GMT

I wonder why they didn't use longs... compare 8 bytes instead

Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

AndyC — Wed, 07 Jan 2009 21:37:50 GMT

Except that Duff's device can't be used in C# (no fall through on cases).

Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Matthew van Eerde — Wed, 07 Jan 2009 20:46:50 GMT

> Comparison loop

Looks like a candidate for Duff's device.

Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Minh — Wed, 07 Jan 2009 20:22:35 GMT

Comparison loop re-written... interesting... 2 chars (4 bytes) are compared at a time... pointer arithmetics... oh my...

int lenA = strA.Length

if (lenA != strB.Length) return false;

char* pA = (char*) strA; // a .Net "char" is 2 bytes
char* pB = (char*) strB;

while (lenA >= 10)
{
   int iA1 = *((int *) pA);
   int iB1 = *((int *) pB);

   int iA2 = *((int *) (pA + 2));   // a .Net "int" is 2 chars (4 bytes)
   int iB2 = *((int *) (pB + 2));

   int iA3 = *((int *) (pA + 4));
   int iB3 = *((int *) (pB + 4));

   int iA4 = *((int *) (pA + 6));
   int iB4 = *((int *) (pB + 6));

   int iA5 = *((int *) (pA + 8));
   int iB5 = *((int *) (pB + 8));

   if (iA1 != iB1 || iA2 != iB2 || iA3 != iB3 || iA4 != iB4 || iA5 != iB5)
   {
      break;
   }

   pA += 10;
   pB += 10;
   lenA -= 10;
}

while (lenA > 0)
{
   int iA1 = *((int *) pA);
   int iB1 = *((int *) pB);

   if (iA1 != iB1)
   {
      break;
   }

   pA += 2;
   pB += 2;
   lenA -= 2;
}

return (lenA <= 0);

Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Matthew van Eerde — Wed, 07 Jan 2009 16:57:12 GMT

> Personally, I always just use "". I find it easier to read...

Hear, hear! Code has three consumers: the compiler, the developer (me) and the person who gets to maintain it later (probably me again after a couple of weeks of not looking at the code.)

Making code easy to read is good for two of these consumers. Performance optimization at the cost of readability had better be mission-critical.

Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Dexter — Mon, 05 Jan 2009 01:14:24 GMT

The "master table" actually exists and it's called "intern pool" but it is not used automatically. You have to explicitly use String.Intern for a string to be stored in that table.

It appears that string literals are automatically interned (I get true for Object.ReferenceEquals(String.Empty, "")) but some said earlier in the thread that they get false so I'm not sure if it happens always. Maybe different runtime versions behave differently.

Funny that if string literals are indeed automatically interned then it's almost as if the C# compiler replaced "" with String.Empty :).

Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Minh — Sun, 04 Jan 2009 23:32:10 GMT

Damn! Somebody want to work on that unrolled loop?

Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Minh — Sun, 04 Jan 2009 23:29:31 GMT

Woweewow, did I ever get it wrong... I never thought that string comparison would be done via char-to-char comparison, but Reflector shows all... What the eff was that master string table I read about? Oh, well, here's what Reflector has to say about string comparison:

public static bool Equals(string a, string b)
{
    return ((a == b) || (((a != null) && (b != null)) && EqualsHelper(a, b)));
}

[ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
private static unsafe bool EqualsHelper(string strA, string strB)
{
    int length = strA.Length;
    if (length != strB.Length)
    {
        return false;
    }
    fixed (char* str = ((char*) strA))
    {
        char* chPtr = str;
        fixed (char* str2 = ((char*) strB))
        {
            char* chPtr2 = str2;
            char* chPtr3 = chPtr;
            char* chPtr4 = chPtr2;
            while (length >= 10)
            {
                if ((((*(((int*) chPtr3)) != *(((int*) chPtr4))) || (*(((int*) (chPtr3 + 2))) != *(((int*) (chPtr4 + 2))))) || ((*(((int*) (chPtr3 + 4))) != *(((int*) (chPtr4 + 4)))) || (*(((int*) (chPtr3 + 6))) != *(((int*) (chPtr4 + 6)))))) || (*(((int*) (chPtr3 + 8))) != *(((int*) (chPtr4 + 8)))))
                {
                    break;
                }
                chPtr3 += 10;
                chPtr4 += 10;
                length -= 10;
            }
            while (length > 0)
            {
                if (*(((int*) chPtr3)) != *(((int*) chPtr4)))
                {
                    break;
                }
                chPtr3 += 2;
                chPtr4 += 2;
                length -= 2;
            }
            return (length <= 0);
        }
    }
}

Re: Why doesn't the C# compiler turn "" into string.Empty?

stevo_ — Sun, 04 Jan 2009 19:39:00 GMT

I think its that concatenation doesn't use the unmanaged string construction which handles interning automatically, although I'm not sure why it does this, perhaps something related to performance of repeating concatenation.

Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Dexter — Sun, 04 Jan 2009 18:45:42 GMT

Wow, did you get it wrong or not :).

So, your a == b will be true but it's not "lighting fast" and it doesn't use the "master table" in any way. Since the == operator is overloaded for strings you get a normal character by character comparison, not a reference comparison. For claritiy

Console.WriteLine("{0} {1}", a == b, Object.ReferenceEquals(a, b));

will print "true false".

This "master table" actually exists but if you want to see its effects you need the following code:

Console.WriteLine("{0} {1}", a == b, Object.ReferenceEquals(a, String.Intern(b)));

This should print "true true". If it doesn't then it means the runtime didn't automatically intern the string literals from the assembly and you need to intern the a string too.

Re: Why doesn't the C# compiler turn "" into string.Empty?

Minh — Sun, 04 Jan 2009 17:07:46 GMT

I think here's why it doesn't matter:

(this is going off memory, but I think it's accurate)
There's a run-time master table of all strings for a .Net app. This is required to implement .Net string immutability system (compare = fast, change = slow). So if you have code like this:

string a = "123";
string b = "12";

b = b + "3";

// At this point a & b share the same reference
// The process involves evaluating b to "123" and doing a look up in the master string table
// and matching b w/ a pre-existing entry (a = "123")

if (a == b) { ... }

// Making the above comparison lighting fast

OK, if you look into the static constructor of the String class, you'll see this:

mscorlib / CommonLanguageRuntimeLibrary / System / String

static String()
{
Empty = "";
...
}

you'll see that an "empty" string value is entered into the master string table very early on, so that comparisons such as

if (a == "")

or

if (a == String.Empty)

is making a comparison the the exact same entry of the table...

I imagine this functionality is built into the ldstr opcode

Re: Re: Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Tommy Carlier — Sat, 03 Jan 2009 13:12:08 GMT

Yeah, it's pretty flexible. It only has to "look like" IEnumerable. I was a bit surprised by the lack of decimal literals.

Re: Why doesn't the C# compiler turn "" into string.Empty?

Christian Liensberger — Sat, 03 Jan 2009 10:23:06 GMT

Btw. Since we are on the topic. Couldn't something like "" vs string.Empty be optimized by the JITter? I mean the whole code is compiled again... something like this could easily be done by the just-in-time compiler... Most people always forget that there's another guy involved after the MSIL has been generated by the C# compiler.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Christian Liensberger — Sat, 03 Jan 2009 10:20:24 GMT

I love how enums are defined in the specs... with the special __value field. I couldn't blieve it when reading. But we're there probably at a level where this needs to be speced that way... After having known that it was obvious why I could set an enum value to everything through reflection.

Re: Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Christian Liensberger — Sat, 03 Jan 2009 10:17:57 GMT

Well try foreach on an object that has not the IEnumerable interface implemented but rather only exposes a GetEnumerator method... will work fine. Nice hack, isn't it?

Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Christian Liensberger — Sat, 03 Jan 2009 10:14:23 GMT

Well... it depends. Since even comparing "" with string.Empty by calling the object.ReferenceEquals method returns true they both might actually represent the same objects on the heap... this could be optimized inside the CLR.

All the checks of evildictaitor result in "true" for me over here (same as Sven)... .NET 3.5 SP1 x86

Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Sven Groot — Sat, 03 Jan 2009 08:00:13 GMT

It's definitely False over here.

It's true here, Vista x64, .Net 3.5 SP1.

As for str == "" versus str.Length == 0, I've always been told the latter performs better though I've never checked it myself. If there's a chance of str being null, using string.IsNullOrEmpty(str) is best of course.

Visual Basic throws some mud into the water since doing str = "" (comparison, not assignment) is actually treated as a special case by the compiler which also evaluates true if str is null (Nothing), similar to string.IsNullOrEmpty(). I never know whether I should comment on that when I use it, since it's a language feature and I don't like writing comments to explain language features, but very few people actually know about this one, and C# developers trying to read VB code will definitely not know about it and might think it's a bug.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

Donald Adu-Poku — Sat, 03 Jan 2009 03:31:52 GMT

Interesting discussion, learning a lot from this.

Re: Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

evildictaitor — Fri, 02 Jan 2009 22:17:18 GMT

Those are defined as part of the C# Ecma specification. String.Empty isn't.

The compiler demands all of the primitives (byte,sbyte,char,string,int16,int32,int64,uint16,uint32,uint64,intptr,uintptr,bool and void), the metatypes (delegate, multicastdelegate, valuetype,object,enum,array), some special types (exception, runtimehandles) some compiler directives (paramsarrayattribute,outattribute) and the interfaces IEnumerable, IDisposable, IEnumerator (with appropriate types on the interfaces) to be defined as part of the ECMA standard for C#. Most everything else in C# is library and syntax sugar.

Re: Why doesn't the C# compiler turn "" into string.Empty?

Bas — Fri, 02 Jan 2009 19:54:51 GMT

Inteesting stuff guys, thanks.

Re: Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

stevo_ — Fri, 02 Jan 2009 19:41:17 GMT

Actually I don't think the C# compiler is aware of IEnumerable (I could be wrong), the foreach really just looks for a member called GetEnumerator() that returns an object that has the members MoveNext and Current (with applicable access and signatures).

Re: Re: Re: Re: Re: Re: Re: Why doesn't the C# compiler turn "" into string.Empty?

stevo_ — Fri, 02 Jan 2009 19:36:59 GMT

I think you'll find project specific extensions become part of the compilation process.. these already happen today as part of 3rd party tools that pull apart IL and re-assemble it (post sharp for example). You seem to be confusing your process of building a compiler with what the extension points in the managed C# compiler will let you do.. its already been demonstated how the .NET C# compiler will work, being able to read source and get a tree that you can freely transform, or even build a tree manually (if you really wanted), then compilation units to take that tree and produce IL.