Part of the code that causes a severe delay in UI

My "Monitor" program has about 15 seconds of delay on a single user's
computer. However, there're no deplay on other users' computers. I've
found that the delay on her computer happens in the line of code
below:

// Loop
foreach (ReportFile lFile in aReport.Files) \\15 seconds
of delay
{
\\blah blah blah
}

I see that it calls numerous methods (including a stored procedure) in
order to get "aReport.Files". I suspect that for the only computer
that has the delay issue, each time when looping "foreach (ReportFile
lFile in aReport.Files)", it calls the numerous methods to get
"aReport.Files" and that's the reason for the extended period of
deplay.

However, I don't have any proof that this is the case on her computer,
since I don't have the deplay issue in my debugger on my computer. In
my debugger, it only executes "aReport.Files" once.

I was thinking of changing this part of the code to below in order to
prevent "aReport.Files" being called multiple times:

ReportFileCollection rptFiles = aReport.Files;

// Loop
foreach (ReportFile lFile in rptFiles )
{


\\blah blah blah
}

Will this solve the delay issue on the user's computer? Thanks!

Re: Part of the code that causes a severe delay in UI

Curious wrote:
> My "Monitor" program has about 15 seconds of delay on a single user's
> computer. However, there're no deplay on other users' computers. I've
> found that the delay on her computer happens in the line of code
> below:
>
> // Loop
> foreach (ReportFile lFile in aReport.Files) \\15 seconds
> of delay
> {
> \\blah blah blah
> }
>
> I see that it calls numerous methods (including a stored procedure) in
> order to get "aReport.Files". I suspect that for the only computer
> that has the delay issue, each time when looping "foreach (ReportFile
> lFile in aReport.Files)", it calls the numerous methods to get
> "aReport.Files" and that's the reason for the extended period of
> deplay.
>
> However, I don't have any proof that this is the case on her computer,
> since I don't have the deplay issue in my debugger on my computer. In
> my debugger, it only executes "aReport.Files" once.
>
> I was thinking of changing this part of the code to below in order to
> prevent "aReport.Files" being called multiple times:
>
> ReportFileCollection rptFiles = aReport.Files;
>
> // Loop
> foreach (ReportFile lFile in rptFiles )
> {
>
>
> \\blah blah blah
> }
>
> Will this solve the delay issue on the user's computer? Thanks!
>

That won't make any difference.

The foreach command calls the GetEnumerator method of the collection.
The enumerator is then used to loop the collection, so the Files
property is actually only called once.

--
Göran Andersson
_____
http://www.guffa.com

Re: Part of the code that causes a severe delay in UI

Göran,

Thanks for confirming this!

One more question: I did have the issue briefly of a delay (for 15
seconds) in my monitor on my computer last Friday.

Through debugging, I found that it was that line of code that caused a
15 seconds of delay. Then I rebooted my computer and the problem went
away from my machine. The deplay was gone.

Therefore, I believe that there is a memoy leak issue on the user's
machine and could be resolved by rebooting the computer. However, the
user refuses to reboot her computer and insists that I find a lasting
and sound solution in the Monitor program.

Is there a method in C#.NET that does the same thing as rebooting the
computer? Such as clearing memory cache? I'll need to use it in the
Monitor program to resolve the user's problem.

Re: Part of the code that causes a severe delay in UI

Does the delay occur on your users PC each time, the same code (and
parameter list is called). When you found the line at fault, was it calling
making a database reference (i.e. inline SQL or stored procedure), or
calling method which in turned reference a database. This could result in
the returned data being cached (on the server, rather than the local
machine) and therefore giving the impression that subsequent calls are
quicker.

Regards,

- Paul Hadfield

"Curious" wrote in message
news:1192061319.851074.172160@o80g2000hse.googlegroups.com.. .
Göran,

Thanks for confirming this!

One more question: I did have the issue briefly of a delay (for 15
seconds) in my monitor on my computer last Friday.

Through debugging, I found that it was that line of code that caused a
15 seconds of delay. Then I rebooted my computer and the problem went
away from my machine. The deplay was gone.

Therefore, I believe that there is a memoy leak issue on the user's
machine and could be resolved by rebooting the computer. However, the
user refuses to reboot her computer and insists that I find a lasting
and sound solution in the Monitor program.

Is there a method in C#.NET that does the same thing as rebooting the
computer? Such as clearing memory cache? I'll need to use it in the
Monitor program to resolve the user's problem.

Re: Part of the code that causes a severe delay in UI

Curious wrote:
> Göran,
>
> Thanks for confirming this!
>
> One more question: I did have the issue briefly of a delay (for 15
> seconds) in my monitor on my computer last Friday.
>
> Through debugging, I found that it was that line of code that caused a
> 15 seconds of delay. Then I rebooted my computer and the problem went
> away from my machine. The deplay was gone.
>
> Therefore, I believe that there is a memoy leak issue on the user's
> machine and could be resolved by rebooting the computer. However, the
> user refuses to reboot her computer and insists that I find a lasting
> and sound solution in the Monitor program.
>
> Is there a method in C#.NET that does the same thing as rebooting the
> computer? Such as clearing memory cache? I'll need to use it in the
> Monitor program to resolve the user's problem.
>

Unless you are allocating unmanaged memory, your application can't leak
memory. Managed memory is completely managed, and there is nothing you
can do to cause a leak.

Unmanaged resources, on the other hand, can possibly be leaked, or much
more commonly, not released in a timely fashion. If you don't dispose of
objects properly, you may run out of things like windows resources or
database connections. Not because they are leaked, but because you are
hanging on to them too long.

--
Göran Andersson
_____
http://www.guffa.com