Performance Stubs

These blog posts are simply times I wanted to identify the fastest method for accomplishing a particular goal. As I write the code, I like to make some light notes of alternatives while driving forward with the first implementation that makes it from my brain to my fingers.

When I get the chance, I can go back and flesh out the two versions and drop them into some basic Stopwatch timing to determine which is better in terms of raw speed. Factoring those results with clarity of code, I have a method I will likely choose the next time I need the same feature.

Goal

Given a particular IEnumerable, find all the elements that are of a particular type (subclass, in this case).

Method 1: Select As, Where Not Null

The as operator with convert between two types with one nice tweak. If the cast cannot happen, it results in null.

In this version, we massage the list by hitting all items with an as cast and then filter out the ones that didn’t cast successfully.

public static IEnumerable<SubSomething> SelectAsWhereNotNull(IEnumerable<Something> source) {
    return source.Select(item => item as SubSomething).Where(item => item != null);
}

Method 2: Where Is, Cast

There is also the is operator. Instead of returning a cast result, it simply returns a boolean for whether the instance can be cast as a given type. From there, we use another Linq extension method: Cast<TResult>.

In this version, we filter the original list to just those that can make the cast successfully, then Cast those items to the final desired type.

public static IEnumerable<SubSomething> WhereIsCast(IEnumerable<Something> source) {
    return source.Where(item => item is SubSomething).Cast<SubSomething>();
}

Test

I built up a list (n=1,000,000) of parent type Something but make every other item a SubSomething (which is a subclass of Something). Then, I run that list through both methods 1000 iterations each.

Results

Clarity

Neither method is particularly difficult to decipher. The Select/Where method takes a few more characters, but not enough to hurt.

Speed

It takes quite a list for these tests to even register with average ticks. That said, there is little gain to be had here over small lists. Once list lengths are sufficiently large, method 1 took the lead.

For n=1,000,000 and 1000 iterations (run on 2.4GHz AMD Phenom 9750 with 8GB RAM)
Average Method
1.0 ticks {IEnumerable<Something>}.Select(item => item as SubSomething).Where(item => item != null)
1.7 ticks {IEnumerable<Something>}.Where(item => item is SubSomething).Cast<SubSomething>()

Performance Testing Framework

The original source for the test framework code evolved from a StackOverflow answer about converting byte arrays to hexadecimal strings. –That code is available in a bitbucket repo. I have adapted it here for these two methods.– That code is available in the framework repo.

Rather than post another repo for each test, I am going to abstract out a testing framework for these posts. That repo will show up soon and I will update this post accordingly.

Update 2013-01-22

I finally refined the testing framework code I was using. While I won’t pretend this code couldn’t use some improvements, feel free to hack away with it. The code is available on GitHub.

To add a new case to an existing test:

  1. Add the new static method (Func<byte[], string>) to /Tests/ConvertByteArrayToHexString/Test.cs.
  2. Add that method’s name to the TestCandidates return value in that same class.
  3. Make sure you are running the input version you want, sentence or text, by toggling the comments in GenerateTestInput in that same class.
  4. Hit F5 and wait for the output (an HTML dump is also generated in the /bin folder).

To add a new test fixture entirely, just write up something that implements IPerformanceTest in that project’s namespace.