Dataset performance impact

[Magnus]

Im using the new binding features of Visual Studio 2005. I have done the
steps to create a bound data source, and selected all 40 tables from the
database. The wizard generated the necessary code for the dataset and can be
seen in the solution explorer under "db_exampledataset.xsd".

My worry is the size of the dataset definition, specifically that the
"db_exampledataset.Designer.cs" is huge, about 51000 lines of code, the
dataset class alone is over 27000 lines of code. And this must have an
impact on performance every time a dataset class is instantiated?

I wonder if there is some sort of strategy around this, is these generated
classes just a joke or is there something I am doing wrong? I thought about
creating several smaller datasets to fit the needs in different areas of the
program, but that seems like a bad idea because if you need to change the
tableadapter associated with one datatable, you will have make sure you also
make any necessary changes in other datasets where its being used, it can
get messy and cumbersome. But that is the only viable solution I have to
this problem right now.

It would be great if you could create lighter datasets that just reference
objects in a master dataset. That way you only have to make changes one
place, and the dataset objects would be smaller.

I also wonder if there is a way, or, what is a good way to measure the
overall performance impact when instantiating and using the dataset object.

- Magnus

 

[OHM \( One Handed Man \)]

You dont have to instantiate the whole dataset, you can instantiate a table
and fill that. However, remember that the dataset is really a class template
and when you instantiate a table, thats all you do.

Dim MyDataTable as new MyDataSet1.MyTableType.


However, I have split my datasets up into logical groupings wherein I may
use relations between the tables, I think when you get to forty tables, it
simple gets way too messy.

 

[Magnus]

You dont have to instantiate the whole dataset, you can instantiate a
table and fill that. However, remember that the dataset is really a class
template and when you instantiate a table, thats all you do.

Dim MyDataTable as new MyDataSet1.MyTableType.

Well, the thing is that when you use the databinding feature in VS2005, it
generates code that instantiate the dataset whenever you want to bind
controls to a datatable that is defined in the dataset.

- Magnus

 

[OHM \( One Handed Man \)]

Sorry, I must have missed that. OK, well do you actually notice a
performance hit and if so what is the magnitude ?

 

[Ian Semmel]

Well, the thing is that when you use the databinding feature in VS2005, it
generates code that instantiate the dataset whenever you want to bind
controls to a datatable that is defined in the dataset.

- Magnus

I'm not 100% convinced that all this wizard stuff like just dragging tables
onto a form and letting VS generate the code is a good thing.

You can do it, then save the Designer file to find out what it is doing and then
delete the table adapters etc from the form and recode the Designer file,
changing things like
this.dataGridViewTextBoxColumn23.Name = "dataGridViewTextBoxColumn23";
into something more meaningful.

These wizards are good at generating "gee whizz" applications for updating
databases with minimal coding, but when you have to do something from a user
specification rather than what the VS designers think you need, things get a bit
harder.

 

[Magnus]

Sorry, I must have missed that. OK, well do you actually notice a
performance hit and if so what is the magnitude ?

What I have noticed is that forms now take a longer time to load, and I use
a pretty fast computer (AMD Athlon XP 2500, 1 gig memory). Meaning that
there is a noticable delay before the form is loaded and the time you click
the button that has the code that instantiate and show the form.

I have not been able to do any measurements as of now, but im really getting
curious as to what the performance hit is. Compared to no dataset
instantiation and for example a dataset with only a few datatable
definitions. I just have to find the appropriate way to measure performance
on code execution.

- Magnus

 

[Magnus]

I'm not 100% convinced that all this wizard stuff like just dragging
tables onto a form and letting VS generate the code is a good thing.

You can do it, then save the Designer file to find out what it is doing
and then delete the table adapters etc from the form and recode the
Designer file, changing things like
this.dataGridViewTextBoxColumn23.Name = "dataGridViewTextBoxColumn23";
into something more meaningful.

This isn't necessary as long as you have meaningfull and consistent naming
on the sql server the generated code is clear as the tool traverses the sql
schema generating the dataset.

These wizards are good at generating "gee whizz" applications for updating
databases with minimal coding, but when you have to do something from a
user specification rather than what the VS designers think you need,
things get a bit harder.

I think you are right, im starting to realise this, and I should have known.
I guess I found the easy implementation of business logics seductive. I
still believe its possible, the important thing is that you have something
flexible to work with.

- Magnus

 

[OHM \( One Handed Man \)]

This is an interesting point. I think perhaps that you may want to consider
reverting back to the user of DataAdapters and split DataSets, as with forty
tables, it would seem that it may be just too much.

Using datasets, is I have found invaludable in terms of clean coding, which
has kept me on the side of typed datasets