By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,099 Members | 2,144 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,099 IT Pros & Developers. It's quick & easy.

when debugging long delay before hitting breakpoint in page load

P: n/a
I am using ASP.Net with VB on the 1.1 Framework running on Win XP Pro.

I am trying to gauge the time it takes to sort a datagrid using different
code sets. But when I am debugging the page there is a long delay before
hitting breakpoint in page load. When I initially load the page I hit the
breakpoint right away. Then I click on a Sort header in a datagrid, and it
takes about 1:45 before the breakpoint (first statement in Page Load) is
encountered. After this I can step through the code very quickly, and there
is no delay when updating the data view and rebinding it to the grid. The
dataset is quite large, and it probably take some time to sort. So it seems
as if all the code is executing first, and then the debugger is letting me
step through it after the fact. Is this correct? Are there any other
possibilities.

Any thoughts are appreciated,

David
Jan 5 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Have you verified that this problem exists only in debugging? Try doing
the sort while not debugging. If the time is the same, it's not a
debugging issue.

BTW, are you caching the dataset, or refetching the data each time? If
caching, where are you storing it?

DCC-700 wrote:
I am using ASP.Net with VB on the 1.1 Framework running on Win XP Pro.

I am trying to gauge the time it takes to sort a datagrid using different
code sets. But when I am debugging the page there is a long delay before
hitting breakpoint in page load. When I initially load the page I hit the
breakpoint right away. Then I click on a Sort header in a datagrid, and it
takes about 1:45 before the breakpoint (first statement in Page Load) is
encountered. After this I can step through the code very quickly, and there
is no delay when updating the data view and rebinding it to the grid. The
dataset is quite large, and it probably take some time to sort. So it seems
as if all the code is executing first, and then the debugger is letting me
step through it after the fact. Is this correct? Are there any other
possibilities.

Any thoughts are appreciated,

David

--
craig
Microsoft MVP - ASP/ASP.NET
Jan 5 '06 #2

P: n/a
- I have tried caching the data, and storing in viewestate with the same
result.
- It takes about the same time to run when not debugging.

It is just odd that I don't even see the Page Load event in the debugger
before the time has elapsed, so it must be executing the code before stepping
through it in the debugger. This just makes it a little difficult to use the
debugger to see where a delay is. Here I know it has to be the sort. I am
just wondering if this is by design, or if there are different settings that
can adjust this.

Thanks for the input,

David

"Craig Deelsnyder" wrote:
Have you verified that this problem exists only in debugging? Try doing
the sort while not debugging. If the time is the same, it's not a
debugging issue.

BTW, are you caching the dataset, or refetching the data each time? If
caching, where are you storing it?

DCC-700 wrote:
I am using ASP.Net with VB on the 1.1 Framework running on Win XP Pro.

I am trying to gauge the time it takes to sort a datagrid using different
code sets. But when I am debugging the page there is a long delay before
hitting breakpoint in page load. When I initially load the page I hit the
breakpoint right away. Then I click on a Sort header in a datagrid, and it
takes about 1:45 before the breakpoint (first statement in Page Load) is
encountered. After this I can step through the code very quickly, and there
is no delay when updating the data view and rebinding it to the grid. The
dataset is quite large, and it probably take some time to sort. So it seems
as if all the code is executing first, and then the debugger is letting me
step through it after the fact. Is this correct? Are there any other
possibilities.

Any thoughts are appreciated,

David

--
craig
Microsoft MVP - ASP/ASP.NET

Jan 6 '06 #3

P: n/a
No, it is not the sort. I tried commenting out the sort, and it still takes
just as long to load. It does not take long to load the page initially, just
on postback. Very weird. Maybe something is timing out before the page is
loading. It is taking the same amount of time to load the page regardless.

Any thoughts?

Thanks,

David

"DCC-700" wrote:
- I have tried caching the data, and storing in viewestate with the same
result.
- It takes about the same time to run when not debugging.

It is just odd that I don't even see the Page Load event in the debugger
before the time has elapsed, so it must be executing the code before stepping
through it in the debugger. This just makes it a little difficult to use the
debugger to see where a delay is. Here I know it has to be the sort. I am
just wondering if this is by design, or if there are different settings that
can adjust this.

Thanks for the input,

David

"Craig Deelsnyder" wrote:
Have you verified that this problem exists only in debugging? Try doing
the sort while not debugging. If the time is the same, it's not a
debugging issue.

BTW, are you caching the dataset, or refetching the data each time? If
caching, where are you storing it?

DCC-700 wrote:
I am using ASP.Net with VB on the 1.1 Framework running on Win XP Pro.

I am trying to gauge the time it takes to sort a datagrid using different
code sets. But when I am debugging the page there is a long delay before
hitting breakpoint in page load. When I initially load the page I hit the
breakpoint right away. Then I click on a Sort header in a datagrid, and it
takes about 1:45 before the breakpoint (first statement in Page Load) is
encountered. After this I can step through the code very quickly, and there
is no delay when updating the data view and rebinding it to the grid. The
dataset is quite large, and it probably take some time to sort. So it seems
as if all the code is executing first, and then the debugger is letting me
step through it after the fact. Is this correct? Are there any other
possibilities.

Any thoughts are appreciated,

David

--
craig
Microsoft MVP - ASP/ASP.NET

Jan 6 '06 #4

P: n/a

DCC-700 wrote:
- I have tried caching the data, and storing in viewestate with the same
result.
- It takes about the same time to run when not debugging.

It is just odd that I don't even see the Page Load event in the debugger
before the time has elapsed, so it must be executing the code before stepping
through it in the debugger. This just makes it a little difficult to use the

It is not executing the code before letting you step through it. Such a
debugger would be pretty pointless. (And wouldn't allow you to move the
execution point)

It's almost certainly the viewstate being reconstructed. If you view
source of the page in the browser, how large is the viewstate field?

Damien

Jan 6 '06 #5

P: n/a
You are correct.

I had left a line of code in Page_Load that was putting the dataset into the
ViewState. So even when I was trying different things in teh data grid sort
command, it was still always loading the dataset into the viewstate. Now the
page loads right away.

Much thanks.

"Damien" wrote:

DCC-700 wrote:
- I have tried caching the data, and storing in viewestate with the same
result.
- It takes about the same time to run when not debugging.

It is just odd that I don't even see the Page Load event in the debugger
before the time has elapsed, so it must be executing the code before stepping
through it in the debugger. This just makes it a little difficult to use the

It is not executing the code before letting you step through it. Such a
debugger would be pretty pointless. (And wouldn't allow you to move the
execution point)

It's almost certainly the viewstate being reconstructed. If you view
source of the page in the browser, how large is the viewstate field?

Damien

Jan 9 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.