Strongly Typed DataSet

  • Thread starter Thread starter Roshawn
  • Start date Start date
R

Roshawn

Hi,

I'm doing a lot of reading in regard to strongly typed datasets. They seem
to be very beneficial as they can reduce the amount of code I have to write
and promote readability.

I am concerned with performance. Is there a performance benefit from using
strongly typed datasets rather than untyped datasets?

Thanks,
Roshawn
 
Hi,

I'm doing a lot of reading in regard to strongly typed datasets. They
seem to be very beneficial as they can reduce the amount of code I have
to write and promote readability.

I am concerned with performance. Is there a performance benefit from
using strongly typed datasets rather than untyped datasets?
Click to expand...

Strongly typed datasets and datatables work with a derived class from
DataRow. You work with DataColumn instances which are used to address the
column in the datarow. This is faster than when you have to lookup the
column via string compare like: ds.Rows[0]["MyField].Value.

Not that much faster though. A dataset is still a bloathed object
when you have to carry around a small amount of data, like 1 row

FB
 
I have been disappointed by this revolation as well. To test the difference
in over head step thru the creation of a typed DataSet and a Generic one.
You will notice a rather significant delay in the instantiation process of
the Typed Dataset.

I also heard a speaker the the Fall 2003 VS Connections conference indicate
that he does not used Typed Datasets in his Data Access Layer because of the
performance hit when doing so.




Frans Bouma said:
Hi,

I'm doing a lot of reading in regard to strongly typed datasets. They
seem to be very beneficial as they can reduce the amount of code I have
to write and promote readability.

I am concerned with performance. Is there a performance benefit from
using strongly typed datasets rather than untyped datasets?
Click to expand...

Strongly typed datasets and datatables work with a derived class from
DataRow. You work with DataColumn instances which are used to address the
column in the datarow. This is faster than when you have to lookup the
column via string compare like: ds.Rows[0]["MyField].Value.

Not that much faster though. A dataset is still a bloathed object
when you have to carry around a small amount of data, like 1 row

FB
Click to expand...
 
Well, "Mr. or Ms. News", I'm of mixed mind when it comes to strongly typed
(or just "typed") DataSets. I think they are a lot of trouble to create.
They require quite a bit of forethought in that you have to know exactly
what they are going to look like at design time. VS.NET will help construct
the XSL and code (quite a bit of it), but this time does not count in the
overall _runtime_ performance hit. But all of this has to be repeated if
the structure changes.
When you instantiate the DataSet, this pre-generated code is executed, and
now you get to refer to the typed DataSet using more precise addressing
which is dramatically faster to execute. However, there is a performance
penalty at instantiation time and, if the Dataset is only expected to live
for an instant (as in an ASP page), I don't see the advantage. Sure, it
takes longer to refer to Tables and "Items" in an untyped DataSet (up to an
order of magnitude longer), if you simply use Enumerations to map the
columns, you can get within a few dozen ticks of strongly typed performance.
This means you should not use "strings" to refer to Tables or Items in your
DataSet--use ordinals.

hth
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

news.microsoft.com said:
I have been disappointed by this revolation as well. To test the difference
in over head step thru the creation of a typed DataSet and a Generic one.
You will notice a rather significant delay in the instantiation process of
the Typed Dataset.

I also heard a speaker the the Fall 2003 VS Connections conference indicate
that he does not used Typed Datasets in his Data Access Layer because of the
performance hit when doing so.




Frans Bouma said:
Hi,

I'm doing a lot of reading in regard to strongly typed datasets. They
seem to be very beneficial as they can reduce the amount of code I have
to write and promote readability.

I am concerned with performance. Is there a performance benefit from
using strongly typed datasets rather than untyped datasets?
Click to expand...

Strongly typed datasets and datatables work with a derived class from
DataRow. You work with DataColumn instances which are used to address the
column in the datarow. This is faster than when you have to lookup the
column via string compare like: ds.Rows[0]["MyField].Value.

Not that much faster though. A dataset is still a bloathed object
when you have to carry around a small amount of data, like 1 row

FB
Click to expand...
Click to expand...
 
Thanks for your response. Your input has helped me a lot.

Roshawn
Frans Bouma said:
Hi,

I'm doing a lot of reading in regard to strongly typed datasets. They
seem to be very beneficial as they can reduce the amount of code I have
to write and promote readability.

I am concerned with performance. Is there a performance benefit from
using strongly typed datasets rather than untyped datasets?
Click to expand...

Strongly typed datasets and datatables work with a derived class from
DataRow. You work with DataColumn instances which are used to address the
column in the datarow. This is faster than when you have to lookup the
column via string compare like: ds.Rows[0]["MyField].Value.

Not that much faster though. A dataset is still a bloathed object
when you have to carry around a small amount of data, like 1 row

FB
Click to expand...
 
I agree that they can be slow to develope if you set up the Typed DataSet by
hand. VS Provides a easy drag and drop capability of creating them from
your datasource.

I noticed your comment that seems to indicate that once you get past the
overhead of instantiating a Typed DataSet the remaining life/use of the
Typed DataSet is much faster on account of it's "precise addressing" was
that your intended meaning?


William (Bill) Vaughn said:
Well, "Mr. or Ms. News", I'm of mixed mind when it comes to strongly typed
(or just "typed") DataSets. I think they are a lot of trouble to create.
They require quite a bit of forethought in that you have to know exactly
what they are going to look like at design time. VS.NET will help construct
the XSL and code (quite a bit of it), but this time does not count in the
overall _runtime_ performance hit. But all of this has to be repeated if
the structure changes.
When you instantiate the DataSet, this pre-generated code is executed, and
now you get to refer to the typed DataSet using more precise addressing
which is dramatically faster to execute. However, there is a performance
penalty at instantiation time and, if the Dataset is only expected to live
for an instant (as in an ASP page), I don't see the advantage. Sure, it
takes longer to refer to Tables and "Items" in an untyped DataSet (up to an
order of magnitude longer), if you simply use Enumerations to map the
columns, you can get within a few dozen ticks of strongly typed performance.
This means you should not use "strings" to refer to Tables or Items in your
DataSet--use ordinals.

hth
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

news.microsoft.com said:
I have been disappointed by this revolation as well. To test the difference
in over head step thru the creation of a typed DataSet and a Generic one.
You will notice a rather significant delay in the instantiation process of
the Typed Dataset.

I also heard a speaker the the Fall 2003 VS Connections conference indicate
that he does not used Typed Datasets in his Data Access Layer because of the
performance hit when doing so.




Frans Bouma said:
Hi,

I'm doing a lot of reading in regard to strongly typed datasets. They
seem to be very beneficial as they can reduce the amount of code I have
to write and promote readability.

I am concerned with performance. Is there a performance benefit from
using strongly typed datasets rather than untyped datasets?

Strongly typed datasets and datatables work with a derived class from
DataRow. You work with DataColumn instances which are used to address the
column in the datarow. This is faster than when you have to lookup the
column via string compare like: ds.Rows[0]["MyField].Value.

Not that much faster though. A dataset is still a bloathed object
when you have to carry around a small amount of data, like 1 row

FB
Click to expand...
Click to expand...
Click to expand...
 
Yup... basically.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

TJO said:
I agree that they can be slow to develope if you set up the Typed DataSet by
hand. VS Provides a easy drag and drop capability of creating them from
your datasource.

I noticed your comment that seems to indicate that once you get past the
overhead of instantiating a Typed DataSet the remaining life/use of the
Typed DataSet is much faster on account of it's "precise addressing" was
that your intended meaning?


William (Bill) Vaughn said:
Well, "Mr. or Ms. News", I'm of mixed mind when it comes to strongly typed
(or just "typed") DataSets. I think they are a lot of trouble to create.
They require quite a bit of forethought in that you have to know exactly
what they are going to look like at design time. VS.NET will help construct
the XSL and code (quite a bit of it), but this time does not count in the
overall _runtime_ performance hit. But all of this has to be repeated if
the structure changes.
When you instantiate the DataSet, this pre-generated code is executed, and
now you get to refer to the typed DataSet using more precise addressing
which is dramatically faster to execute. However, there is a performance
penalty at instantiation time and, if the Dataset is only expected to live
for an instant (as in an ASP page), I don't see the advantage. Sure, it
takes longer to refer to Tables and "Items" in an untyped DataSet (up to an
order of magnitude longer), if you simply use Enumerations to map the
columns, you can get within a few dozen ticks of strongly typed performance.
This means you should not use "strings" to refer to Tables or Items in your
DataSet--use ordinals.

hth
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Click to expand...
process
of
the Typed Dataset.

I also heard a speaker the the Fall 2003 VS Connections conference indicate
that he does not used Typed Datasets in his Data Access Layer because
Click to expand...
of
the
performance hit when doing so.





Hi,

I'm doing a lot of reading in regard to strongly typed datasets. They
seem to be very beneficial as they can reduce the amount of code I have
to write and promote readability.

I am concerned with performance. Is there a performance benefit from
using strongly typed datasets rather than untyped datasets?

Strongly typed datasets and datatables work with a derived class from
DataRow. You work with DataColumn instances which are used to
Click to expand...
address
the
column in the datarow. This is faster than when you have to lookup the
column via string compare like: ds.Rows[0]["MyField].Value.

Not that much faster though. A dataset is still a bloathed object
when you have to carry around a small amount of data, like 1 row

FB
Click to expand...
Click to expand...
Click to expand...
 
Back
Top