What makes this code slow

[dbuchanan]

This code resets a form with two cbo's (comboBoxes) and one datagrid.
The first cbo (cboSelection) selects a main table and filters the
second cbo. The second cbo (cboView) selects the secondary table which
determine the dataAdapter used to fill the dataGrid. Both cbo's are
populated by filling dataAdapters.

This code just empty's the datagrid, cbo's and dataset so the user can
start over to view another set of data.

\\
Private Sub btnResetForm_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles btnResetForm.Click

'Clear the datagrid
Me.DataGrid1.DataSource = Nothing
Me.DataGrid1.TableStyles.Clear()

'clear the dataset
_dataSet1.Clear()

DAL.da010JobFrm.Fill(_dataSet1, "tbl010Job")

'cboSelection
Me.cboSelection.DataSource = _dataSet1
Me.cboSelection.DisplayMember = "tbl010Job.JobNumber"
Me.cboSelection.ValueMember = "tbl010Job.pkJobId"

_bStillLoadingCboSelection = False

_bStillLoadingCboView = True

End Sub
//

What makes this code slow?

It is as slow as if it was about to throw an error.

Or How can I test this code?

Thank you,
dbuchanan

[Robbe Morris [C# MVP]]

Data binding is slow. I'd bet you could
load the combobox faster with your own code.

Did you try trapping errors and see if
one is being generated?

--
Robbe Morris - 2004/2005 Microsoft MVP C#
EggHeadCafe's RSS Search Engine
http://www.eggheadcafe.com/articles/...h/default.aspx


"dbuchanan" <db*********@hotmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

This code resets a form with two cbo's (comboBoxes) and one datagrid.
The first cbo (cboSelection) selects a main table and filters the
second cbo. The second cbo (cboView) selects the secondary table which
determine the dataAdapter used to fill the dataGrid. Both cbo's are
populated by filling dataAdapters.

This code just empty's the datagrid, cbo's and dataset so the user can
start over to view another set of data.

\\
Private Sub btnResetForm_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles btnResetForm.Click

'Clear the datagrid
Me.DataGrid1.DataSource = Nothing
Me.DataGrid1.TableStyles.Clear()

'clear the dataset
_dataSet1.Clear()

DAL.da010JobFrm.Fill(_dataSet1, "tbl010Job")

'cboSelection
Me.cboSelection.DataSource = _dataSet1
Me.cboSelection.DisplayMember = "tbl010Job.JobNumber"
Me.cboSelection.ValueMember = "tbl010Job.pkJobId"

_bStillLoadingCboSelection = False

_bStillLoadingCboView = True

End Sub
//

What makes this code slow?

It is as slow as if it was about to throw an error.

Or How can I test this code?

Thank you,
dbuchanan

[dbuchanan]

Hi Robbe,

Thank you for your reply.

I use the binding all over in my code for comboBoxes and it appears
instantaneous. This block of code is *exceptionally* slloooooowwww!

There is one thing I do a little differently in this block compared to
others but it raised no flags with me for reasons I will explain.

In other code I clear a dataTable with code like this;

'clear the datatable
_dataSet1.tbl040Cmpt.Clear()

but in this block I clear the entire dataset with this code;

'clear the dataset
_dataSet1.Clear()

This has not reaised any flags for me (#1) because there are only a
coulple of tables involved. The reason I clear the dataset instead of
tables is that I don't know which tables it will be - it depends on
user selection.

Another reason (#2) that it has not raised a flag with me is that
subsequaint calls to this block are instantaneous even though the same
numbers of tables are loaded.

Any clues to what might cause this type of behavior?

Did you try trapping errors and see if one is being generated?

I put this block within a try catch block. That did not bring up any
errors. Is there another way to expose errors that I might get me more
results - I'm sort-of new at trapping errors.

Thank you,
dbuchanan

[Robbe Morris [C# MVP]]

DAL.da010JobFrm.Fill(_dataSet1, "tbl010Job")
--
Robbe Morris - 2004/2005 Microsoft MVP C#
Free Source Code for ADO.NET Object Mapper To DataBase Tables And Stored
Procedures
http://www.eggheadcafe.com/articles/..._generator.asp


"dbuchanan" <db*********@hotmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

This code resets a form with two cbo's (comboBoxes) and one datagrid.
The first cbo (cboSelection) selects a main table and filters the
second cbo. The second cbo (cboView) selects the secondary table which
determine the dataAdapter used to fill the dataGrid. Both cbo's are
populated by filling dataAdapters.

This code just empty's the datagrid, cbo's and dataset so the user can
start over to view another set of data.

\\
Private Sub btnResetForm_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles btnResetForm.Click

'Clear the datagrid
Me.DataGrid1.DataSource = Nothing
Me.DataGrid1.TableStyles.Clear()

'clear the dataset
_dataSet1.Clear()

DAL.da010JobFrm.Fill(_dataSet1, "tbl010Job")

'cboSelection
Me.cboSelection.DataSource = _dataSet1
Me.cboSelection.DisplayMember = "tbl010Job.JobNumber"
Me.cboSelection.ValueMember = "tbl010Job.pkJobId"

_bStillLoadingCboSelection = False

_bStillLoadingCboView = True

End Sub
//

What makes this code slow?

It is as slow as if it was about to throw an error.

Or How can I test this code?

Thank you,
dbuchanan

[dbuchanan]

Hi Robbe,

The code takes a full five seconds on the first call. It is
instantaneous on each call thereafter.

1.) open the windows form
2.) select the job in the first comboBox
3.) select the view in the second comboBox
.... view the data in the datagrid
4.) Click the Reset button to make another selection
....
....
....
....
.... wait a ful 5 seconds for the form to reset (datagrid and combo
boxes are cleared and reset)
5.) select the job in the first comboBox
6.) select the view in the second comboBox
.... view the data
7.) Click the Reset button
instantaneous reset ready for the user to begin another selection.

Thank you,
dbuchanan

[Cor Ligthert [MVP]]

dbuchanan,

Deleting datarows is extremely slow in the version 1.x. This is one of the
points that was especially a point for improvement in 2.0.

I don't know how that affects the clear.

However, why don't you try what creating a new dataset does. The old one
will be automaticly than be deleted by the GC when there is a better time
for that.

I hope this helps,

Cor

[dbuchanan]

Cor, Robbe, Anybody,

Deleting datarows is extremely slow in the version 1.x.

I don't think we're on the right track. - The problem exists only in
this form's clear and only the first time. It is clearing the same
amount of data the second time.

How can I go about detecting what is happening in this code? Or where
exactly the bottleneck is?

Stepping through the code in debug mode is not good enough. It only
shows what I know already... When I step past "_dataSet1.Clear()" the
first time there is a long delay. after populating the form again and
clicking the "reset" button the second time a step past
"_dataSet1.Clear()" is instantaneous. Why? Why does it take so long the
first time? Why is it no problem the second time an all times
thereafter? There *is* a reason! How can I track it down?

Thank you,
dbuchanan

[Cor Ligthert [MVP]]

dbuchanan,

Can it be that the dataset is already empty in this case. I thought to
remember me that I have seen that in version 1.x the exception is used to
check that.

That could than explain the situation.

Cor

[david]

On 2005-09-18, dbuchanan <db*********@hotmail.com> wrote:

Cor, Robbe, Anybody,

Deleting datarows is extremely slow in the version 1.x.
I don't think we're on the right track. - The problem exists only in
this form's clear and only the first time. It is clearing the same
amount of data the second time.

How can I go about detecting what is happening in this code? Or where
exactly the bottleneck is?

Two thoughts. Attach handlers to the various dataset and datatable
events, to see if you can narrow down exactly where the delay is.

Even more useful probably, go into Debug-Exceptions and set all CLR
exceptions to break into the debugger. This should tell you if
the first Clear is throwing exceptions for some reason.

Also, do you have the same delay if you aren't running in DEBUG mode?
That would be a good sign of exceptions, since exceptions are much, much
slower in a debugger.


Stepping through the code in debug mode is not good enough. It only
shows what I know already... When I step past "_dataSet1.Clear()" the
first time there is a long delay. after populating the form again and
clicking the "reset" button the second time a step past
"_dataSet1.Clear()" is instantaneous. Why? Why does it take so long the
first time? Why is it no problem the second time an all times
thereafter? There *is* a reason! How can I track it down?

Thank you,
dbuchanan

[dbuchanan]

Hi David,

I'm kinda new at this debugging thing...

Attach handlers to the various dataset and datatable events
Could you give me an example of how to do this?
go into Debug-Exceptions and set all CLR exceptions to break into the debugger
Could you explain to me how to navigate to this and what to do when I
get there?
do you have the same delay if you aren't running in DEBUG mode?

The delay in Release mode seems to actually run a little longer than in
DEBUG mode (by about one second).

Thank you,
dbuchanan

[david]

On 2005-09-18, dbuchanan <db*********@hotmail.com> wrote:

Hi David,

I'm kinda new at this debugging thing...

Attach handlers to the various dataset and datatable events
Could you give me an example of how to do this?

For each dt As DataTable in MyDataSet
AddHandler dt.RowChanging, AddressOf RowHandler
AddHandler dt.RowChanged, AddressOf RowHandler
.. and so on

Inside the handler, trace some timing information to see if you can
narrow down the problem. Unfortunately some of the handlers have
different signatures, so you'll need to define a few of them. If this
still doesn't make sense, look up AddHandler and Event in the
documentation.

go into Debug-Exceptions and set all CLR exceptions to break into the debugger

Could you explain to me how to navigate to this and what to do when I
get there?

Umm, click the Debug menu, choose the Exceptions options, click on the
CLR Exceptions items, and make sure the "Break Into the Debugger" radio
button is clicked on.

do you have the same delay if you aren't running in DEBUG mode?

The delay in Release mode seems to actually run a little longer than in
DEBUG mode (by about one second).

Then it's probably not exceptions.

[C-Services Holland b.v.]

dbuchanan wrote:

This code resets a form with two cbo's (comboBoxes) and one datagrid.
The first cbo (cboSelection) selects a main table and filters the
second cbo. The second cbo (cboView) selects the secondary table which
determine the dataAdapter used to fill the dataGrid. Both cbo's are
populated by filling dataAdapters.

This code just empty's the datagrid, cbo's and dataset so the user can
start over to view another set of data.

\\
Private Sub btnResetForm_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles btnResetForm.Click

'Clear the datagrid
Me.DataGrid1.DataSource = Nothing
Me.DataGrid1.TableStyles.Clear()

'clear the dataset
_dataSet1.Clear()

DAL.da010JobFrm.Fill(_dataSet1, "tbl010Job")

'cboSelection
Me.cboSelection.DataSource = _dataSet1
Me.cboSelection.DisplayMember = "tbl010Job.JobNumber"
Me.cboSelection.ValueMember = "tbl010Job.pkJobId"

_bStillLoadingCboSelection = False

_bStillLoadingCboView = True

End Sub
//

What makes this code slow?

It is as slow as if it was about to throw an error.

Or How can I test this code?

Thank you,
dbuchanan

Is there a chance that the query used is slow?

[dbuchanan]

David,

Thank you for your patience at my inexperience.

Following your suggestions I was able to identify the cause of and
elimate two NullReferenceExceptions. I had not disabled the cbo event
while clearing them and I was getting nullreferences on their
selectedValueChanged event. I changed to AddHandler/RemoveHandler to
control this event rather than using conditionals. There is still a
delay, but it is a little shorter. It no longer occurs at the dataset
clear statement.

The delay is no less of a mystery!
Using Debug-Exceptions set to break into the debugger with CLR
exception as you suggested, I get a System.ArgumentOutOfRangeException
for each call to fill using the dataAdapter;

DAL.da010JobFrm.Fill(_dataSet1, "tbl010Job")
DAL.da002ViewList.Fill(_dataSet1, "lst002ViewList")

The myster here is that both these statemetns filled the dataset tables
moments ago with no errors prior to executing the reset button. And
what does ArgumentOutOfRange mean when filling a dataSet?

What would cause such strange behavior?

Thank you,
dbuchanan

[dbuchanan]

Thank you for your reply,

I don't think so for these reasons;
· The query is very simple
· Under other circumstances it runs instantaneous.
· Issues other than the query seem to be emerging

dbuchanan