first exception pause

  • Thread starter Thread starter Marek
  • Start date Start date
M

Marek

What can I do in order to avoid first exception pause?
I am sure everyone already experienced this behavior and there must be a
solution.

regards
 
Well, I thought it was a well known issue.

Anyway, the problem is that when an exception occurs for the first time,
application is "freezed" for a couple of seconds.
When further exceptions occur, there is no problem, they are raised
immediately without blocking the application.
The problem seems to be only with the first one.

Has anybody experienced such situation? Are there any solutions?

reagrds
 
I think I got your point. I experienced this kind of scenario before
however, it was in a particular method call. If I can remember it
correctly, I have this method that always take some time the first time it
executes. The next time it execute again, I can observe the increase in
performance (speed wise). My hunch before is that the .NET framework
behaves just like the stored procs of SQL that it somewhat uses caching, JIT
just reuses the same method the second time it encounters the method. It
only had the slower speed performance on the first call where JIT tries to
compile it for the first time.

I don't really know, anyone who has a better insight?
 
Marek said:
Well, I thought it was a well known issue.

Anyway, the problem is that when an exception occurs for the first time,
application is "freezed" for a couple of seconds.
When further exceptions occur, there is no problem, they are raised
immediately without blocking the application.
The problem seems to be only with the first one.

Has anybody experienced such situation? Are there any solutions?
Click to expand...

It's interesting - I was commenting on this just the other day.

I had a test program which *used* to pause for a second, but doesn't
seem to any more. It's possible that the upgrade to .NET 1.1 SP1 has
improved things.

I don't know the exact cause, but one thing you could consider is
queuing a ThreadPool work item which just throws (and catches) an
exception at startup. That way you shouldn't have any problems later
on.
 
Thank you, Jon.
Nice idea.

reagrds
Marek

Jon Skeet said:
It's interesting - I was commenting on this just the other day.

I had a test program which *used* to pause for a second, but doesn't
seem to any more. It's possible that the upgrade to .NET 1.1 SP1 has
improved things.

I don't know the exact cause, but one thing you could consider is
queuing a ThreadPool work item which just throws (and catches) an
exception at startup. That way you shouldn't have any problems later
on.
Click to expand...
 
I've seen similar behaviour when program was running in debug configuration
under VS.NET sometimes.
However the pause wasn't present in release config without vs.net.
 
I've seen the same problem and had "fixed" it the same way as you
suggested - throw and swallow an exception in a background thread. One
possible reason why some products exhibit this while others don't is that
there may be exceptions thrown during startup by portions of the BCL that it
swallows, so the delay is build right into the app startup time.

I believe one of the causes of the delay is that the runtime has to
interpret the contents of the stack to build the stack trace, and this
requires loading additional assemblies and code, parsing the stack, etc.
Another is that the code path an exception takes involves trips through the
kernel, notifications sent to the debugger port via the Win32 subsystem,
etc., such that lots of DLLs need to get loaded that are not normally
loaded.
 
David Levine said:
I've seen the same problem and had "fixed" it the same way as you
suggested - throw and swallow an exception in a background thread. One
possible reason why some products exhibit this while others don't is that
there may be exceptions thrown during startup by portions of the BCL that it
swallows, so the delay is build right into the app startup time.

I believe one of the causes of the delay is that the runtime has to
interpret the contents of the stack to build the stack trace, and this
requires loading additional assemblies and code, parsing the stack, etc.
Another is that the code path an exception takes involves trips through the
kernel, notifications sent to the debugger port via the Win32 subsystem,
etc., such that lots of DLLs need to get loaded that are not normally
loaded.
Click to expand...

Yes, that was my thought too. What's interesting though is that on my
laptop, where IO is much slower than the CPU, when I was able to
reproduce this, the CPU was 100% busy while the exception was being
thrown. That suggests it's more than just loading stuff. Definitely
odd.
 
Yes, that was my thought too. What's interesting though is that on my
laptop, where IO is much slower than the CPU, when I was able to
reproduce this, the CPU was 100% busy while the exception was being
thrown. That suggests it's more than just loading stuff. Definitely
odd.

--
Click to expand...
Hmmm, yes; it's hard to tell what that really means. It suggests it is
performing some sort of internal calculation, but it could be operating
system related as opposed to a runtime issue.

Ah well, I suppose what this *really* means is that we will be buying
new/faster/better hardware and help keep Dell/Gateway et al in business.
Perhaps 64 bit computers will be the magic bullet that makes all performance
related issues disappear :-)
 
Hmmm, yes; it's hard to tell what that really means. It suggests it is
performing some sort of internal calculation, but it could be operating
system related as opposed to a runtime issue.

Ah well, I suppose what this *really* means is that we will be buying
new/faster/better hardware and help keep Dell/Gateway et al in business.
Perhaps 64 bit computers will be the magic bullet that makes all performance
related issues disappear :-)
Click to expand...

It looks like it only happens in debug, actually, so we shouldn't
really worry about performance for releasing our products in these
terms.
 
Back
Top