Archive | October 2012

Static vs Instance string.Equals Benchmark

A friend of mine commented on my last post asking about how much faster the static string.Equals method is than the instance string.Equals method. To satiate both of our curiosities, I have created this benchmarking application:

static void Main(string[] args)
{
    var stopwatch = new Stopwatch();

    string a = "hello";
    string b = "hi";

    stopwatch.Start();
    for (int i = 0; i < 10000000; i++)
    {
        a.Equals(b);
    }
    stopwatch.Stop();

    Console.WriteLine("Instance string.Equals over 10,000,000 iterations: " + stopwatch.ElapsedMilliseconds + " ms");

    stopwatch.Reset();

    stopwatch.Start();
    for (int i = 0; i < 10000000; i++)
    {
        string.Equals(a, b);
    }
    stopwatch.Stop();

    Console.WriteLine("Static string.Equals over 10,000,000 iterations: " + stopwatch.ElapsedMilliseconds + " ms");

    Console.ReadKey();
}

The results of 5 runs, where “I” is the instance method and “S” is the static method, and the times are in milliseconds:

I: 113
S: 100

I: 144
S: 96

I: 126
S: 89

I: 126
S: 94

I: 128
S: 97

And there you have it. Static string.Equals is reliably slightly faster… But unless you’re doing millions of comparisons, it probably doesn’t really matter much. It does, however, prevent the NullReferenceException mentioned in the last post when the string instance is null.

Static vs Instance string.Equals

As you may or may not know, static methods are usually faster than instance methods. This alone should be a good enough reason to use the static string.Equals method in .NET, but if that doesn’t do it for you, allow me to present a simple example.

string a = "hello";
string b = "hi";
bool result = a.Equals(b);

What is the expected result of these lines? A boolean value of false, of course. And it’d be true if the strings were identical. It’s also false if b is null. But what if a is null?

string a = null;
string b = "hi";
bool result = a.Equals(b);

The above code throws a NullReferenceException, since we are attempting to use the instance method of string.Equals and our instance is null. Effectively we’re calling null.Equals which of course is a NullReferenceException.

The static method is best to use in situations where either string (or both) can be null. Re-writing our code as:

string a = null;
string b = "hi";
bool result = string.Equals(a, b);

Allows the code to run identically in function to the original code but without ever throwing a NullReferenceException for any given string input.

The Joel Test Really is Meaningful

Well, it’s been nearly 2 months since my last post… I’m learning that if you want a blog to be successful, you have to carve time out of your busy life and make it happen. So, with renewed focus, I re-enter the fray.

The Joel Test is a curious and honest thing. It has been around since the year 2000 and was invented by a guy named Joel Spolsky, as the name might imply. In short, it’s a very brief questionnaire that evaluates the quality of your software development team, and implicitly their happiness as well.

There are 12 questions. A score of 12 is perfect, 11 is good, 10 or lower and your team has serious problems. The questions are simple and in the format of yes/no. The Joel Test is as follows:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

For those who have never heard of hallway usability testing, I offer Joel’s definition: “A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.”

The Joel Test has been in and out of my life for quite some time. Every now and then I remember that it exists, and then I evaluate my current employer on it. My current company is suffering in the programming department; we are losing people like crazy and are having a hard time hiring good folks, despite offering reasonably competitive salaries and benefits… So, realizing that we have some issues, I conducted The Joel Test on a whim. Here’s how we did:

1. Do you use source control? Yes.
2. Can you make a build in one step? Yes.
3. Do you make daily builds? No.
4. Do you have a bug database? Yes.
5. Do you fix bugs before writing new code? No.
6. Do you have an up-to-date schedule? No.
7. Do you have a spec? No.
8. Do programmers have quiet working conditions? No.
9. Do you use the best tools money can buy? No.
10. Do you have testers? Yes.
11. Do new candidates write code during their interview? No.
12. Do you do hallway usability testing? No.

We scored 4. 4 out of 12. Recall that 10 or worse means that you have a serious problem. Yeah.

So, what did I learn? I learned that part of the reason that we are losing people is that our programming practices and team environment lack something to be desired, and thus people are not happy. This isn’t really news to me, however, since the people that have quit recently have all cited these things as some of the main reasons.

What’s the next play? We need to improve the aspects of our environment and team that failed the test. The question then becomes: will management improve these things, or will they choose to ignore our suggestions because most of them (using the best tools that money can buy, quiet working conditions) cost money, and the rest of them are process changes? In fact, I’d go so far as to say that for my current company, they’d be significant process changes… And if there’s one thing that I’ve learned in my career as a programmer so far, it’s that businesses love to stay in familiar territory, clinging to what they already know and feel experienced in, and are generally afraid of significant change.

As a result of the change not being delivered, the motivated individual realizes that change must then come from within… People quit to change the negative environment for themselves (by joining a more positive one).

I encourage you all to conduct The Joel Test in your environments, and to try and improve your team with the results. What have you got to lose? Oh yeah, more developers. 😉