Getting Distinct from a List

Sometimes you have a list of complex objects that you need to pare down to be a list of distinct complex objects.  LINQ offers a way to do that, but unless you've done it before it's not immediately obvious as to what you need to do.  There are two ways to do it, and they're actually pretty easy to implement.

If the complex object is your own creation, just implement IEquatable where T is the type of the object.  Something like this:



Once you've implemented IEquatable on your class, you just have to invoke the .Distinct() call on your list.  Here you go:



Here are the results of the IEquatable approach:


If you find yourself in a situation where the complex object can't be extended to implement IEquatable, there's a solution for that, too.  You'll create an additional class that implements IEqualityComparer and then specify that when you invoke the .Distinct() call on your list.







Here are the results of using the IEqualityComparer approach:

Going Loopy for Performance (C#)

I may have written about this before, and if so, I apologize.  Wait, no I don't.  I couldn't find it and this blog is for me anyway.  I retract my apology.  Anyway, if you've ever wondered whether your loop is as fast as it can be, I have some answers for you.

I read one time that a for loop is faster than a foreach loop in C#.  I can buy that, I suppose.  But in the same article it said that iterating backward through a for loop is faster than iterating forward and I had a hard time getting on board with that.  So I wrote some tests.  That author was right.

I wanted to test a variety of options, so I did.  That's how I roll.  I ran each test over 100,000,000 iterations.

The first test was a regular for loop:

...and the results:


Next up I did the same thing but without previously specifying the size of the loop (I use .Count as the upper limit of the loop):

...and the results:


You can see that of the two options, it is slightly faster to set the upper limit in a variable.  "Slightly" here meaning 11 milliseconds over 100,000,000 iterations, or .00000011 milliseconds per iteration.

Moving on.  Next we have the reason for my testing in the first place: the reverse for loop:

...and the results:


Whoa!  That's a bit of an improvement.  37 milliseconds over 100,000,000 iterations (compared to our previous best time), or .00000037 milliseconds per iteration.

This time the reverse loop without a variable:

...and the results:


Based on the earlier results of the forward for loop, this makes sense.  Next was a foreach loop over a list:

...and the results:


Wow.  That's a significant degradation.  Our previous worst time (a forward for loop with a variable as our upper bound) was 240 milliseconds.  The foreach on a list (which is, in my opinion, the easiest loop to write) takes nearly twice as long to run.

Last up is a foreach loop on an array instead of a list:

...and the results:


The overall results certainly point to a reverse for loop with a variable as the lower bound is the fastest we can iterate through an array.

BUT WAIT, THERE'S MORE!  I found this last bit while I was writing this up.  It's an alternative way to do a decrementing for loop that's actually slightly faster than anything else up there.

...and the results:


I learned a couple of lessons on this one.  First, don't always go with the easiest thing to do because it may not be the best thing to do.  Second, minor functions can have major performance implications.  In this example, I just incremented a variable during the iteration, but in a real world scenario I may do anything from build a complex object to make a service call.  This basic example showed us a difference of 279 milliseconds over 100,000,000 iterations.  That is a really small number per iteration, but keep in mind that the only thing we were doing was incrementing a counter.  If we had been doing any real work that would have been a major performance hit.

Tracing with Unity

One of the most consistent issues that comes up with software is the need to improve performance.  Even if your application is really fast 99% of the time, someone will want you to improve it at some point.  That's just a fact of life.  The problem is that it's really hard to improve the overall performance of your application if you don't know where the performance is lacking.

I once had a boss who, upon learning that the performance of the new application was not to his standards, demanded that we fix it immediately.  When we pressed him for what was slow he answered "all of it" and "just the whole thing".  We said "let us put some logging in place so we can identify which parts are too slow and then we'll fix it", which was met with "no, just fix it now".

Ever since that incident, I've made it a point to build in a tracing feature that can be switched on or off with a small change to the configuration file.  Recently (as in, two days ago) I found that the old way of tracing wasn't working for me anymore and I had to figure out how to do it all over again.  Here is the fruit of my labor.

First, create the TraceCallHandler class:


Here's some more detail on that one:



The Invoke method is the one that actually interrupts the call.  You can see that all we're doing here is building the arguments list, getting the name of the method being called (including the type in which it's declared in case you have the same method name in multiple places), and starting a stopwatch around the actual method call.  We let the method do its thing, then log the whole shebang on a new thread.



I struggled with this one for a while, but ultimately settled on this.  Basically, I'm trying to see what parameters were used to call the method being executed.  This is helpful when the parameters are primitive types, but if a complex object is passed, it doesn't tell me a whole lot.



Basically at this point we're just passing the values we've collected into a stored procedure so we can review the data when we're ready.  And on that note, here's the stored procedure:



Aaaaaaand the table that stored procedure writes to:



To use the trace attribute all you have to do is add it as a decorator to the interface that has the methods you want to trace.  In this case we're going to trace all methods on the IAboutManager class:



But that'll only work if we configure tracing back in our Unity container.  Like this:



And then we have to configure the actual trace on the IAboutManager interface, like this:



And that's it.  That little bit of code (OK, it's a lot of code, but it did all fit in a single post) will enable tracing with two values from the web.config set to true.  Oh, I forgot that part.  Here you go: