[Mono-dev] Faster

Rodrigo Kumpera kumpera at gmail.com
Thu Mar 24 12:51:35 EDT 2011


Mono uses zero cost exception handling, so setting up a try-catch handler
has zero cost.

That's the theory, but using try-catch blocks have a few undesirable
implications to control-flow.
The problem are variables that are used in the catch block, for example:

int x;
try {
  x = 1;
  MayThrow ();
  x = 2;
  MayThrow ();
  x = 3;
} catch (Exception) {
  Console.WriteLine (x);
}

On the above code, when we reach the catch block, we can't statically know
which assignment was the last to execute, so we have
to make sure they all use the same storage - which is a very hard problem to
solve.

Mono's current JIT takes the easy solution which is to mark all those
variables as volatile, which has the unfortunate effect of producing
code outside the catch block that is quite worse than otherwise. So, EH has
a very low overhead, but should not be used for those cases.

Now onto the null check. Such a null check will exploit a cpu feature known
as branch prediction, which guesses the outcome of the
conditional jump. Since in the majority of the cases the value won't be
null, the cpu can pretend the branch doesn't exist and keep executing
as it was not taken. This means the null check costs virtually nothing on a
modern cpu.



On Thu, Mar 24, 2011 at 5:32 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote:

> Hi,
>
> I'm not an expert on the JIT compiler and such, but I do know that in
> virtually all programming languages that support exception handling, the
> cost of a null-check is infinitesimal compared to the cost of setting up
> an exception handler.  On many systems, setting up a try-catch handler
> costs something like 200 instructions whereas the null check only costs
> one or two instructions.
>
> Cheers,
> Mikael
>
> Den 24-03-2011 17:06, Steve Bjorg skrev:
> > Is the cost of the if-null check greater than setting up an exception
> catch handler?
> >
> > - Steve
> >
> > ---------------------------------
> > Steve G. Bjorg
> > MindTouch
> > San Diego, CA
> >
> > 619.795.8459 office
> > 425.891.5913 mobile
> > http://twitter.com/bjorg
> >
> > On Mar 24, 2011, at 9:00 AM, Miguel de Icaza wrote:
> >
> >> Hello guys,
> >>
> >> Today in the shower I had an idea that I believe we could use to
> >> improve the performance of our class library code.
> >>
> >> Plenty of our class library code has code like this:
> >>
> >> void Foo (Something x)
> >> {
> >>     if (x == null)
> >>         throw new ArgumentNullException ("x");
> >>     x.DoSomething ();
> >>     x.AndThenMore ();
> >> }
> >>
> >> Arguably, if this could be inlined, and the JIT could prove that x is
> >> not null, we would skip the first test, for example:
> >>
> >> Foo (new Something ());
> >>
> >> But this is the exception, in general, the JIT would not be able to
> >> know this kind of information for even trivial uses like:
> >>
> >> Foo (Bar.GetSomething ());
> >>
> >> Rendering the optimization not very effective.
> >>
> >> But what if we changed our code in Foo across our class libraries to
> >> do this instead:
> >>
> >> void Foo (Something x)
> >> {
> >>     try {
> >>         x.DoSomething ();
> >>     } catch (NullReferenceException e){
> >>         if (x == null)
> >>              throw new ArgumentNullException ("x");
> >>         else
> >>               throw;
> >>     }
> >>     x.AndThenMore ();
> >> }
> >>
> >> This has the advantage that the test for the value of "x" being null
> >> is delayed until we actually need it.    The downside of course is
> >> that DoSomething could actually take other forms and might end up
> >> running code that we do not need before it touches x, for example,
> >> this would be a problem:
> >>
> >> // We should never add null values.
> >> void AddToCache (Something x)
> >> {
> >>     cache.Add (x);
> >> }
> >>
> >> void Foo (Something x)
> >> {
> >>       if (x == null)
> >>           throw new ArgumentNullException ("x");
> >>       AddToCache (x);
> >> }
> >>
> >> If we rewrite the above code, we would end up with a bug like the one
> >> I described.
> >>
> >> Miguel
> >> _______________________________________________
> >> Mono-devel-list mailing list
> >> Mono-devel-list at lists.ximian.com
> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20110324/2dfcddac/attachment-0001.html 


More information about the Mono-devel-list mailing list