posted on Tuesday, May 18, 2004 10:04 PM by taylorza

Performance - String Equality

Before I even start this blog, I want to point out that the results contained in here are relative and would hardly alter the overall performance of your application except is some very rare and extreme cases. This was merely and intellectual exercise for which I am making my results available.

In my current role I am often assessing performance bottle necks within existing code and as you might know from my other blog entries I subscribe to the school of "profile profile profile optimize test test test profile profile profile…" As part of developing my understanding of potential performance bottle necks I often inspect the IL for any unexpected code being generated.

While readers of my blog (are there any?) will know that my language of choice is C#, but currently I find myself doing more and more VB.NET code. And it is with VB.NET that I find many instances where the convenience of the language sometimes yields less than effective runtime code for the unsuspecting developer. While there are a number of these instances which I hope to be discussing over the next few blogs I want to start with the one that surprised me. And that is the simple equality operator which in VB.NET is ‘=’ and for C# it is ‘==’.

When the C# compiler encounters a == operator on strings it generates a call to the op_Equality method of the string class. When the VB.NET compiler encounters the seemingly corresponding = operator it rather generates a call to Microsoft.VisualBasic.CompilerServices.StringType.StrCmp, this is to maintain a functional compatibility with VB6 code. My immediate reaction was to determine the impact of this difference in terms of performance, particularly when invoked in a lengthy loop which is primarily composed of string comparisons. So I devised a series of simple tests, these are by no means complete and lack some obvious permutations such as reference equality, but I believe they do cover a fair number of typical cases within an application.

Test 1 : Compare two instances of a string with the same binary pattern

Test 2 : Compare two instances of a string with a binary pattern differing only towards the end of the string

Test 3 : Compare a string against a null or VB.NET nothing

These tests where carried out using the following comparison operations, where S1 and S2 are two strings and the samples use VB.NET syntax.

· Microsoft.VisualBasic.CompilerServices.StringType.StrCmp()

S1 = S2

· op_Equality

S1.op_Equality(S2)

· instance.Equals

S1.Equals(S2)

· String.Equals

String.Equals(S1, S2)

I also performed the tests using a different length of string, the first being 11 characters and the second run contained 100 characters.

The following graphs show the relative performance of these tests.


The tests where run using VS.NET 2003, VB.NET .NET, Framework 1.1 running Windows 2003.

Conclusion

While I would never suggest that VB.NET developers abandon the ‘=’ equals operator because of the inefficiency. I would definitely bear these results in mind when performing an operation which has high volumes and is string comparison intensive in which case I would consider using the String.Equals as an alternative.

Related Post: Performance - Case insensitive string comparisons

Comments