Re: perf & Try Catch

From: Jon Skeet [C# MVP] (skeet_at_pobox.com)
Date: 01/01/05


Date: Sat, 1 Jan 2005 15:14:13 -0000

David Levine <noSpamdlevineNNTP2@wi.rr.com> wrote:
> > Having had a look at the JITted code, I think it's more a case of the
> > JIT not being able to optimise as heavily, not being able to enregister
> > as much.
>
> There may be additional housekeeping that isn't obvious just from the JITted
> code. Also, did you compile with debug or release settings? (it could make a
> difference in how aggressive the optimizations are).

I compiled without any specific optimisation or debug settings (just
the default) which I believe isn't particularly optimised, but doesn't
have debug information either.

> > Personally I think that apart from a very, *very* few situations,
> > exception handling should be implemented according to elegant design
> > rather than optimal performance. In the case we're talking about, the
> > processing within the loop would have to be *very* simple for the cost
> > of adding the try/catch to end up being particularly significant.
>
> I agree completely - design for correctness first, then go back and look at
> optimizations as needed. However, this only came up because a statement was
> made that there was no cost at all to using a try block, and that statement,
> as far as I can tell, is false.

Agreed. I think I'd say "virtually no cost" to give an appropriate
impression of how small it is in comparison with almost any other
performance penalties, but it's non-zero. At least, it is in some
cases... it could well be that if the JIT is already hampered by other
characteristics of the method, there really *is* no cost. That's a bit
more than I'm willing to investigate atm :)

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


Relevant Pages

  • Re: perf & Try Catch
    ... > Having had a look at the JITted code, I think it's more a case of the ... > JIT not being able to optimise as heavily, ... difference in how aggressive the optimizations are). ... > exception handling should be implemented according to elegant design ...
    (microsoft.public.dotnet.languages.csharp)
  • JIT compiler optimizations (inlining threshold too low?)
    ... I noticed that the performance of the JIT optimizer has not improved as much ... I know that there is a tradeoff between JIT optimizations and startup speed. ... public static Complex Zero ... double xre, xim, cre, cim, t; ...
    (microsoft.public.dotnet.framework.performance)
  • Re: JIT Optimizations Lacking!
    ... Nathan Zaugg wrote: ... performed during the JIT compilation is not nearly as good as the ... optimizations done by C++ at compile time. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: optimized code
    ... > loop invariants are handled by the JIT not by the compiler fron-ends. ... generates the best optimized MSIL of any of the .NET languages. ... standard native code optimizations on MSIL code. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: optimized code
    ... All depends on what exactly you are measuring, how you are comparing and ... produced by the C++ compiler, when enabling max. optimizations (enables the ... > "Floating Point?The v1 JIT does not currently perform all the FP-specific ... > optimizations that the VC++ backend does, ...
    (microsoft.public.dotnet.languages.csharp)