Re: Sending exceptions across domains and threads
- From: "Vagif Abilov" <vagif@xxxxxxxxx>
- Date: Wed, 10 Aug 2005 12:39:52 +0200
Thank you David.
Just for your information. I have written a small app to test performance
implications of exceptions (including scenario with cross-domain
marshalling). It's available here:
http://www.codeproject.com/useritems/ExceptionPerformance.asp
Vagif
"David Levine" <noSpam12dlevineNNTP2@xxxxxxxxx> wrote in message
news:%234UsUpTnFHA.576@xxxxxxxxxxxxxxxxxxxxxxx
>
> "Vagif Abilov" <vagif@xxxxxxxxx> wrote in message
> news:eqinISMnFHA.3828@xxxxxxxxxxxxxxxxxxxxxxx
>> There is an excellent set of guidelines about rules to throw exceptions:
>>
>> http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx
>>
>> Two very important statements:
>>
>> Do not return error codes. Exceptions are the primary means of reporting
>> errors in frameworks.
>>
>> Do not use error codes because of concerns that exceptions might affect
>> performance negatively.
>>
>> I'd love to accept these rules. The world looks much more consistent with
>> them. But! What about multiple threads and domains?
>
> Multiple threads are not an issue. Exceptions always occur on a single
> thread, and for them to be propagated to a different thread the exception
> must be rethrown on the secondary thread. This is true whether the thread
> is bounded by a single appdomain or if the thread transitions between
> multiple appdomains.
>
>
> Error codes will always be faster then exceptions because there is far
> less overhead associated with stuffing a value into a stack location then
> with going through the full 2 phase stack walk that is incurred with an
> exception.
>
>> We have a system that needs to execute calls across different AppDomains.
>> If we replace error codes with exceptions, the performance implication
>> will be huge. Really. I know Microsoft is always trying to be ahead of
>> hardware development (which is wise). But the cost of serializing
>> exceptions is so high that we are really concerned about it. What do you
>> think?
>
> The performance hit caused by exceptions is mainly due to the stack walk
> overhead, and this will be incurred regardless of the appdomain boundary.
> The appdomain boundary presents additional issues, such as changes in the
> security context, but this is present whether you use exceptions or error
> codes. It is true that the exception must be serialized, but unless you
> are calling a method in a tight loop across the boundary the extra
> performance hit should not be significant. If this is occuring in a tight
> loop then you will have other performance problems besides that of
> exceptions. You should not use exceptions to report those types of
> errors - they are most useful when used in the low-performance code path.
>
> Bottom line: all engineering consists of trade-offs. If you are writing a
> performance intensive application, or an operating system, then you may
> need to go to extraordinary lengths to achieve your performance goals, but
> for most applications it is better to use exceptions rather then error
> codes.
>
>>
>> Vagif Abilov
>> Oslo Norway
>> vagif-at-online.no
>>
>
>
.
- References:
- Sending exceptions across domains and threads
- From: Vagif Abilov
- Re: Sending exceptions across domains and threads
- From: David Levine
- Sending exceptions across domains and threads
- Prev by Date: Cryptography- RSA
- Next by Date: Number of physical threads
- Previous by thread: Re: Sending exceptions across domains and threads
- Next by thread: Cryptography- RSA
- Index(es):
Relevant Pages
|
