when debugging long delay before hitting breakpoint in page load

5 Jan 2006 11:18 PM

DCC-700

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

5 Jan 2006 11:24 PM

Craig Deelsnyder

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:
Show quoteHide quote

> 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

6 Jan 2006 1:58 PM

DCC-700

- 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

Show quoteHide quote

"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
>

6 Jan 2006 3:00 PM

DCC-700

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

Show quoteHide quote

"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
> >

6 Jan 2006 3:04 PM

Damien

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

9 Jan 2006 1:51 PM

DCC-700

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.

Show quoteHide quote

"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
>
>