Rodrigo, Thanks for the detailed explanation. That's really good to know!
- Steve -------------- Steve G. Bjorg http://mindtouch.com http://twitter.com/bjorg On Mar 24, 2011, at 9:51 AM, Rodrigo Kumpera wrote: > 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 <mik...@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@lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list