Do Strongly Typed Datasets improve performance?

Question

Where I work we're finally coming around to the idea of using strongly typed datasets to encapsulate some of our queries to sqlserver. One of the idea's I've been touting is the strength of the strongly typed column's, mainly for not needing to cast any data. Am I wrong in thinking that strongly-typed-datasets would improve performance in the following situation where there could be potentially thousands of rows?

old way:

using(DataTable dt = sql.ExecuteSomeQuery())
{
    foreach (DataRow dr in dt.Rows)
    {
        var something = (string)dr["something"];
        var somethingelse = (int)dr["somethingelse"];
    }
}

new way:

MyDataAdapter.Fill(MyDataset);
foreach (DataRow dr in MyDataset.MyDT.Rows)
{
    var something = dr.Something;
    var somethingelse = dr.SomethingElse;
}

If the properties are really just doing the casting behind the scenes, I can see how there wouldn't be any speedup at all; perhaps it would take even longer then before with the overhead of the function call in the first place.

Are there any other performance strengths / weaknesses of using DataSets we should know about?

Thanks!

Answer 1

I'm not sure if there will be any performance improvements using the strongly typed datasets, however you get the added type safety, and with it compiler errors when you mistype a field name, for example.

There's an article in MSDN magazine about them, to quote a line in it:

The speed in accessing a typed DataSet is comparable to the faster techniques in accessing an untyped DataSet (since a typed DataSet is just a layer over an untyped DataSet) and the readability of the typed DataSet is the best

Also, as Stuart B pointed out, the Intellisense alone makes it worthwhile.

Answer 2

Don't forget Intellisense. It's delicious.

Answer 3

Technically speaking, there should be a small performance hit from creating a strongly typed dataset. Although, creating a strongly typed dataset brings a lot of benefits. In terms of maintainability and programming. On top of Intellisense, if something changes in your data access layer, you wont have to search for everything like "column 1". You just have to change where you actually assign the values to the object.

This is similar to the 'is linq worth the performance hit.' It's slower, but the slight in speed is worth the increased productivity level.

Answer 4

Strongly typed DataSets are just a strongly typed wrapper over the same untyped DataSet that you would otherwise use. With the assumption that you would use the untyped DataSet in a reasonable, efficient manner, a strongly typed DataSet would not be faster (execution-wise).

Answer 5

Yes, there is a benefit from using strongly typed datasets - and that is from column lookup. Looking up the column by name is slower than looking up the column by type. The code generated for strongly-typed datasets looks up columns by type, so you get a bit of a performance boost.

Answer 6

If you look at the code generated for a typed dataset, you can see that under each typed call is a call made with the string indexed name. So, they really offer no performance gains, only type safety.

I do have a major gripe with nullable fields in typed datasets however. Specifically, if you access an int field which is null, it throws an exception.. you have to call the IsMyfieldNull() call first to determine if it is a null, and avoid referencing it if it is. A real solution for this would be allow nullable type fields, so you do not risk the chance of throwing an exception just for touching a field. This flaw in my mind almost negates the benefits of the stong typing.