Tag: my_team

I recommend using these standards when reading values from a DataRow.

• Prefer not to use the as operator with the DataRow indexer because it hides type conversion errors and it is slower than other options.
• Use the Field extension method from System.Data.DataSetExtensions.dll for value-type columns that allow DBNull.
• Use casting for columns that do not allow DBNull.
• Prefer checking DataRow.IsNull and casting for nullable reference types

The extension methods Field and SetField are in System.DataSetExtensions.dll (System.Data namespace).

// Instead of using the as operator to access a DateTime? type column...
var entryDate = row["entry_date"] as DateTime?;
// Use the Field extension method instead.
var entryDate = row.Field<DateTime?>("entry_date");

All the signatures that the DataRow indexer accepts are accepted by the Field method.

It really is more of a type-safety and understanding/clarity issue than performance. Timings for 50 million calls (I recommend uses in blue) :

DateTime, AllowDBNull = true, not-null:

 row.Field<DateTime?>(column)                        4172 ms Type-safe and fastest
 row.IsNull(column) ? null : (DateTime?)row[column]  9722 ms
 row[column] as DateTime?                            9025 ms Hides InvalidCastException

DateTime, AllowDBNull = true, null:

 row.Field<DateTime?>(column)                        3935 ms Type-safe and pretty fast
 row.IsNull(column) ? null : (DateTime?)row[column]  3080 ms
 row[column] as DateTime?                            5429 ms Hides InvalidCastException

DateTime, AllowDBNull = false, not-null:

 row.Field<DateTime>(column)                         4639 ms
 (DateTime) row[column]                              2708 ms Type-safe and fast

String, AllowDBNull = false, not-null:

 row.Field<string>(column)                           3362 ms
 (string) row[column]                                1317 ms Type-safe and fast

String, AllowDBNull = true, not-null:

 row.Field<string>(column)                           3467 ms less to type, typesafe, slower.
 row.IsNull(column) ? null : (string) row[column]    2106 ms A lot to type, but fast
 row[column] as string                               1320 ms Hides InvalidCastException

String, AllowDBNull = true, null:

 row.Field<string>(column)                           2857 ms less to type, typesafe, slower.
 row.IsNull(column) ? null : (string) row[column]    1182 ms A lot to type, but fast
 row[column] as string                               1279 ms Hides InvalidCastException

Please try to use the IsNull method on DataRow to determine if a value is null or not. DataRow/DataColumn does not actually store null or DBNull – it has a BitArray that says whether or not a non-null value is stored in which columns in the row.  Retrieving the column’s value for the row creates a copy of the DBNull.Value structure which doesn’t get created when calling the IsNull method.  Ideally this performance difference is never observable, but I feel it does tend to make the code cleaner and is the more correct implementation.

// This is better than any of the many possible 
// variations of checking the value

myDataRow.IsNull(someColumnName)

// discouraged

myDataRow[someColumnName].Equals(DBNull.Value)

myDataRow[someColumnName] == DBNull.Value

myDataRow[someColumnName] is DBNull

!(myDataRow[someColumnName] is Int32) // (or appropriate type)

This is a repost of this one updated to use ReSharper 4.1…

What could be wrong with this class?  Think carefully and post your answer in the comments. 

 

class Something
{
      public string ServiceName { get; private set; }
      public int DbId { get; private set; } 

      public Something(string serviceName, int dbId)
      {
            if (serviceName == null) throw new ArgumentNullException("serviceName");
            ServiceName = serviceName;
            DbId = dbId;
      } 

      public override int GetHashCode()
      {
            return ServiceName.GetHashCode() + DbId;
      } 

      public override bool Equals(object obj)
      {
            Something other = obj as Something;
            return other != null && DbId == other.DbId && ServiceName == other.ServiceName;
      }
}
 

I was wondering if I already knew an object was a string if it was faster to cast it or to call ToString().  I thought it would be faster to call ToString() because casting has to do some type checking while the String class overrides ToString to return itself:

public class String
{
     //...

     public override string ToString()
     {
          return this;
     }
}

By this reasoning, I figured that (a is string && a.ToString().Length < 4000) would be cheaper than (a is string && ((string)a).Length < 4000).  

It turns out they are both six IL instructions:  

Calling ToString  

L_0007: ldloc.0
L_0008: isinst string
L_000d: brfalse.s L_0023
L_000f: ldloc.0
L_0010: callvirt instance string [mscorlib]System.Object::ToString()
L_0015: callvirt instance int32 [mscorlib]System.String::get_Length() 

Casting  

L_0025: ldloc.0
L_0026: isinst string
L_002b: brfalse.s L_0041
L_002d: ldloc.0
L_002e: castclass string
L_0033: callvirt instance int32 [mscorlib]System.String::get_Length() 

So… now what is the cost difference between the castclass operator and the virtual method call to the ToString method?  

Turns out the cast takes about 75% of the time of a ToString call. 

using System;
static class Program
{
      static void Main()
      {
            object o = "a string";
            string a;
            string b;
 
            Boolean r = (o is string && o.ToString().Length < 4000);
            r = (o is string && ((string)o).Length < 4000);
 
            DateTime t = DateTime.Now;
            for (int i = int.MinValue; i < int.MaxValue; i++)
                  a = (string)o;
            Console.WriteLine(DateTime.Now - t);
 
            t = DateTime.Now;
            for (int i = int.MinValue; i < int.MaxValue; i++)
                  b = o.ToString();
            Console.WriteLine(DateTime.Now - t);
      }
}

When implementing an interface explicitly, it is best to create virtual methods or properties if you ever expect a subclass to need to change the behavior.  Implementing the interface explicitly helps to not pollute the public members of a type, but subclasses cannot reach the superclass’s implementation if they have to reimplement the interface to change the behavior.  Exposing protected methods for the explicitly implemented members would keep the public interface clean while still allowing access by subclasses.
 
Somewhere I read a post from one of the .NET Framework developers that confirmed the superclass’s implementation would be unreachable in situations such as the one below.  You can find more on Google: http://groups.google.com/groups/search?hl=en&q=explicit+interface+base+c%23 

// Reimplementation of explicit interface implementation makes
// superclass implementation inaccessable from subclass.
 
internal class Program
{
      private static void Main()
      {
            I i = new B();
            System.Console.WriteLine(i.Stuff());
            i = new C();
            System.Console.WriteLine(i.Stuff());
      }
}
 
internal interface I
{
      int Stuff();
}
 
internal class A : I
{
      protected int count = 0;
 
      int I.Stuff()
      {
            return 1;
      }
}
 
/// <summary>
/// Normal code can't get there.
/// </summary>
internal class B : A, I
{
      int I.Stuff()
      {
            count++;
            if (count > 100)
            {
                  System.Console.WriteLine("Infinite loop");
                  return -1;
            }
 
            // Doesn't compile, not allowed to use "base" here.
            // return 2 + ((I)base).Stuff();
 
            return 2 + ((I) ((A) this)).Stuff();
      }
}
 
/// <summary>
/// Even Reflection can't get there.
/// </summary>
internal class C : A, I
{
      int I.Stuff()
      {
            count++;
            if (count > 100)
            {
                  System.Console.WriteLine("Infinite loop");
                  return -1;
            }
 
            System.Reflection.MethodInfo stuffMethodOfI;
            stuffMethodOfI = typeof (A).GetInterface("I").GetMethod("Stuff");
            return 2 + (int) stuffMethodOfI.Invoke((A) this, null);
      }
} 

 Output: 

Infinite loop
199
Infinite loop
199 

DataView slowWay = new DataView(table);
slowWay.RowFilter = rowFilter;

DataView fastWay = new DataView(table,
                                rowFilter,
                                String.Empty,
                                DataViewRowState.CurrentRows);