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

first exception pause

P: n/a
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
Nov 16 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
What exactly did you mean by "first exception pause"?

"Marek" wrote:
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

Nov 16 '05 #2

P: n/a
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

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:B8**********************************@microsof t.com...
What exactly did you mean by "first exception pause"?

"Marek" wrote:
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

Nov 16 '05 #3

P: n/a
This is weird...i haven't experienced this issue before. Could you post the
code as well?

"Marek" wrote:
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

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:B8**********************************@microsof t.com...
What exactly did you mean by "first exception pause"?

"Marek" wrote:
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


Nov 16 '05 #4

P: n/a
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" <ma**************@sbcglobal.net> wrote in message
news:dR*****************@newssvr31.news.prodigy.co m...
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

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:B8**********************************@microsof t.com...
What exactly did you mean by "first exception pause"?

"Marek" wrote:
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


Nov 16 '05 #5

P: n/a
Marek <ma**************@sbcglobal.net> wrote:
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?


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #6

P: n/a
Thank you, Jon.
Nice idea.

reagrds
Marek

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marek <ma**************@sbcglobal.net> wrote:
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?


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #7

P: n/a
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.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marek <ma**************@sbcglobal.net> wrote:
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?


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #8

P: n/a
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.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marek <ma**************@sbcglobal.net> wrote:
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?


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #9

P: n/a
David Levine <no****************@wi.rr.com> wrote:
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.


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #10

P: n/a
>
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.

--

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 :-)

Nov 16 '05 #11

P: n/a
David Levine <no****************@wi.rr.com> wrote:
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.
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 :-)


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

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.