Intelligent Design : Code

A Little Christmas Coding Magic

FTProductDev — Thu, 13 Dec 2007 07:01:00 GMT

When I was a kid I loved magic - simple card tricks to Copperfield’s million dollar illusions, I was easily mesmerized and mystified. People have been bending what we THINK is reality for years. Take a look at the picture - Which way does this window face. Are the people on the inside looking to the left or looking to the right? Are you looking up into the window, or are you looking down into the window?

Same thing goes for programming – what we type out in code does not always translate to "what is" during execution; especially if you’re dealing with a compiler between what you write and assembled code delivered into production.

Take the battle between a couple of conditional processing structures provided in C# (and most other languages): Who’s “better” regarding efficiency and elegance - a switch (case) statement or If-Else conditional statement. The GoOracle would tell you this is a no brainer, and logically we would assume that switch would perform better because the framework does not have to evaluate each statement in the flow.

Let’s assume otherwise and challenge the norm given the following code in pre-compiled form:

private static void SwitchSingleCondition() {

Stopwatch timer = new Stopwatch();

timer.Start(); // Start the timer

string compare = "a";

for (long i = 1; i <= 10000; i++) {

switch (compare) {

case "a":

compare = "b";

break;

case "b":

compare = "a";

break;

default:

compare = "a";

break;

}

timer.Stop(); // Stop the timer

Console.WriteLine("Execution time for 'Switch Single Condition' was {0:F1} microseconds.", (decimal)timer.Elapsed.Ticks / 10M);

}

private static void IfSingleCondition() {

Stopwatch timer = new Stopwatch();

timer.Start(); // Start the timer

string compare = "a";

for (long i = 1; i <= 10000; i++) {

if (compare == "a") {

compare = "b";

} else if (compare == "b") {

compare = "a";

} else {

compare = "a";

}

timer.Stop(); // Stop the timer

Console.WriteLine("Execution time for 'If Single Condition' was {0:F1} microseconds.", (decimal)timer.Elapsed.Ticks / 10M);

}

When executed we get the following results:

Why did the “if statement” run more efficiently than the switch? Let’s pull back the curtain and take away the mirrors – this is what the code looks like after compilation (Reflector you rock!):

private static void SwitchSingleCondition()

{

Stopwatch timer = new Stopwatch();

timer.Start();

string compare = "a";

for (long i = 1L; i <= 0x2710L; i += 1L) {

string CS$0$0000 = compare;

if (CS$0$0000 == null) {

goto Label_004B;

}

if (!(CS$0$0000 == "a")){

if (CS$0$0000 == "b"){

goto Label_0043;

}

goto Label_004B;

}

compare = "b";

continue;

Label_0043:

compare = "a";

continue;

Label_004B:

compare = "a";

}

timer.Stop();

decimal CS$0$0000 = timer.Elapsed.Ticks / 10M;

Console.WriteLine("Execution time for 'Switch Single Condition' was {0:F1} microseconds.", CS$0$0000);}

private static void IfSingleCondition()

{

Stopwatch timer = new Stopwatch();

timer.Start();

string compare = "a";

for (long i = 1L; i <= 0x2710L; i += 1L) {

if (compare == "a"){

compare = "b";

}

else if (compare == "b"){

compare = "a";

}

Else {

compare = "a";

}

timer.Stop();

decimal CS$0$0000 = timer.Elapsed.Ticks / 10M;

Console.WriteLine("Execution time for 'If Single Condition' was {0:F1} microseconds.", CS$0$0000);

}

Are you kidding me – the “if” logic even looks more elegant! So what happened? It seems that behind the smoke, mirrors, and assumptions the .NET framework looks at the code that was written and restructures it to what it thinks will be more efficient using if-else conditions, “goto” statements, and a labeling system. Once your case statement exceeds 4 conditions the compiler will leave the code alone and execute it as a normal switch case.

It turns out that if-else-if statements can and most likely will be more efficient than switch statements when the number conditions do not exceed four. Things aren't always what they seem. Don’t be blinded by the magic – challenge your assumptions - until they become fact.

--nick

Plasma, Dog Plasma: Generics vs. Objects

FTProductDev — Tue, 04 Dec 2007 06:36:00 GMT

I came across an interesting quote from Tony Northrup regarding .net Generics:

“I haven’t been able to reproduce the performance benefits of generics; however, according to Microsoft, generics are faster than using casting. In practice, casting proved to be several times faster than using a generic. However, you probably won't notice performance differences in your applications.”

That reminded me of a 1954 cartoon called "Crazy Mixed Up Pup." There was a Doctor who was given a couple bottles of plasma but couldn't figure out which to use on the dog and which to use on the man - pure genius. While I hope I am never faced with the decision of which bottle of plasma to wire up to dog or man, I often face the struggle of pulling out the right tool for a given need.

For instance, .net has several different types of collections, not to mention generic collections introduced in 2.0, and others introduced by the community. Let's face it, our tool bags are getting bigger, more robust - what do we do when we're introduced to things like Tony's discovery?

I chose to put together a little project to see if I could reproduce his findings and dig out the right tool...

1. Created a console application

2. Then 2 classes

a. Object with two public members that where of type System.Object

b. Generic with two public members that were generic types

using System;

using System.Collections.Generic;

using System.Text;

namespace ObjectVSGenerics {

class Program {

static void Main(string[] args) {

RunTest(Console.ReadKey().Key);

Console.ReadLine();

}

private static void RunTest(System.ConsoleKey key) {

Int64 start = DateTime.Now.Ticks;

for (int i = 0; i <= 1000000; i++) {

if (key == ConsoleKey.O) {

Obj o = new Obj(1, 1);

int objInt = o.sum();//(int)o.obj1 + (int)o.obj2;

} else if (key == ConsoleKey.G) {

Gen<int, int> g = new Gen<int, int>(1, 1);

int genInt = g.t + g.u;

}

Int64 processingSeconds = (DateTime.Now.Ticks - start) / TimeSpan.TicksPerMillisecond;

Console.WriteLine(" Process time in Milliseconds " + key.ToString() + ": " + (processingSeconds).ToString());

Console.Write("Enter another: ");

RunTest(Console.ReadKey().Key);

}

This is what I found:

Build / Framework	Generic mean exec time	Object mean exec time	% Efficiency
Debug .net 2.0	32ms	77ms	58% (Generic)
Debug .net 3.0	33ms	78ms	57% (Generic)
Debug .net 3.5	33ms	80ms	59% (Generic)
Release .net 2.0	15ms	64ms	76.5% (Generic)
Release .net 3.0	15ms	58ms	74% (Generic)
Release .net 3.5	15ms	57ms	74% (Generic)

Now, while I was not able to reproduce Tony’s findings and the scenario above was not a “real world” scenario (looping and instantiating an object or generic 1 million times in a given execution) I was able to conclude a few things:

· The efficiency of the generic was higher than the object, and the efficiency of both were higher when executing Release code. It makes total sense why a release build would be faster, especially regarding recursion (the framework is less aggressive about cleaning up resources in debug code, plus other optimizations). However, why did the object stay close to the same execution mean and the generic become roughly 50% faster?

o Check out this post by the C# team. Basically this improvement is because the actual implementation is created at runtime. So when I create Gen<int, int> the JIT will see if it has previously been compiled and if it has will reuse it. Secondly the Object implementation will always require boxing and unboxing of the value type int – that simply will not change, Release or not.

· In this book Tony points out that a really good reason to use Generics is simply because they are type-safe. Meaning that during compilation if a value you’re providing to your generic does not match the instantiated instance’s definition the compiler will error. Generic code is only valid if it will compile every possible instance of the generic.

· Finally, if you notice in the code above I created a method in the Object class to encapsulate the “sum” functionality. Normally, you probably would not do this because when dealing with objects - you’re already running the risk of no type safety during runtime. But to make a point – Generics cannot perform this sort of encapsulation; operators cannot be used as logic mechanisms. When generic code is compiled it maintains its “generic-ness.” Therefore anything that would explicitly require a certain type will not compile.

The bottom-line is “real-world” forces you to use all of the tools in your tool bag, not just the cool ones. We love adopting new technologies at Fellowship Technologies; we have to ride the razor’s edge to be able to evaluate and use the best that is out there so that we can build the best.

Generics seem to have a pretty significant advantage over objects and casting - it's a tool, I think, that has the possibility of make some solid, clean, and fast code.

--nick

Choppin' properties

nfloyd — Mon, 21 May 2007 17:30:00 GMT

C# Enumerations have always been a sore area for developers. Binding (lack of), comparison, explicit conversion, etc...

Over all enumerations are good mechanisms to help you avoid hitting the database - for predefined system types. So what happens if your type has some sort of metadata hanging off of it and you still want to use a static representation of the data?

Let's say you have an entity named communication and it has a two properties hanging off of it:

public Enum.CommunicationType CommunicationType{get{}set{}}

public string CommunicationValue {get{}set{}}

Enum.CommunicationType represents the following:

public enum CommunicationType{
      HomePhone = 1,
   CellPhone = 2,
   Email = 3,
   AlternateEmail = 4,
   WebAddress = 5,
   IMAddress = 6
}

Now let’s say you want to validate the “CommunicationValue” in your business layer based on

CommunicationType, but CommunicationType does not tell us the intended context of value, just a label for the value. So how do we tell the code to interpret values associated with communication types “HomePhone” or “CellPhone” that they should be validated as phone numbers?

Associate custom properties with the enum values and use reflection to access those properties when needed. Here's how:

First make your custom property to be implemented by the enumeration (note: custom properties can be used by several different targets - reference the System.AttiributeTargets namespace for the list).

Something like:

[AttributeUsage(AttributeTargets.Enum)]

public class MetaData : System.Attribute {

private string _value = null;

public MetaData(string value) {

_value = value;

}

public string Value {

get {return _value;}

}

So now only enumerations may implement our MetaData class. We’re only allowing a get in this interface – if you wanted to you could overload the constructor passing in many data types and add properties to the class to extend functionality. For instance, if you wanted to pass a regular expression as well as the “value” for validation during reflection you could do so by simply adding another interface and adding another property.

Next, we will use the MetaData class to help describe our Enumeration valueType. For simplicity we will use strings to describe our data.

public enum CommunicationType{
    [MetaData("PhoneNumber")]HomePhone = 1,
  [MetaData("PhoneNumber")]CellPhone = 2,
  [MetaData("Email")]Email = 3,
  [MetaData("Email")]AlternateEmail = 4,
  [MetaData("Web")]WebAddress = 5,
  [MetaData("Web")]IMAddress = 6
}

You can do this next part several different ways, we will use the GetField method hanging off of the Type:

CommunicationType ct = (CommunicationType)_communicationTypeID;

FieldInfo fi = ct.GetType().GetField(ct.ToString());

if (fi != null) {

MetaData[] attributes = (MetaData[])fi.GetCustomAttributes(typeof(MetaData), false);

if (attributes.Length > 0) {

if (attributes[0].Value != null) {

generalType = attributes[0].Value;

}

You can opt out of using the indexers on the attributes by iterating the attribute collection and finding your attribute if there were more than your specific implementation.

That’s it, dump the code in some BC util method or store it in your Communication entity as a helper method – passing in the enumeration instead of declaring it (like above) and you have instant attributes. The reflection cost is very minimal since we’re dealing with either valueTypes or very simple referenceTypes.