If you’re not a VB.Net or C# geek, probably best to move on to the next post. But if you are, perhaps someone can explain to me the what the !@#%! is going on here.
While hacking away on a new code project which involved porting a routine from VB6 to VB.Net (4.5 framework), I discovered that my performance had gone completely to hell on a function which assembles a big text file from database values. In it, I tracked the trouble to a function checks to see if certain values from the database were null, and returns “safe” values in case they are. It also looks for telltale “null” date fields, with values like 12/31/1899 which–although not technically null, are acting as blank for these purposes.
Here’s code sample #1:
Public Shared Function ConvertNulls( _ ByVal theString As Object) As String ... If IsDBNull(theString) Then ConvertNulls = "" ElseIf theString = "12:00:00 AM" OrElse theString = _ "12/31/1899" OrElse theString= "12/30/1899" Then ConvertNulls = "" ' This is a null date string Else ConvertNulls = theString End If ... End Function
And code sample #2:
Public Shared Function ConvertNulls( _ ByVal theString As Object) As String ... If IsDBNull(theString) Then ConvertNulls = "" ElseIf theString.Equals("12:00:00 AM") _ OrElse theString.Equals("12/31/1899") _ OrElse theString.Equals("12/30/1899") Then ConvertNulls = "" ' This is a null date string Else ConvertNulls = theString End If ... End Function
Here’s the thing:
Code sample #1 was on track to take a hour or so to run through 100,000 iterations; code sample #2 did the same 100,000 iterations in about 20 seconds. And the only difference? Whether I used theString = “x” or theString.equals “x”
Luckily, I thought to try .equals pretty early on, or else I’d be pulling my hair out trying to figure out why there should be even a tiny difference between the two approaches. Can anyone out there give me a coherent explanation as to why using the “=” operator vs. the .equals method should yield such wildly different performance results?