[Mono-dev] Faster

[Atsushi Eno]

Agreed, though the suggestion may still work if the type has 
op_Equality() overload.

Atsushi Eno

(2011/03/25 1:31), Stifu wrote:
> > From my experience, null checks are really, really cheap, to the point I've
> had troubles measuring any difference between code paths with and without
> null checks. So, to me, this sounds like more troubles than it's worth, and
> time better spent elsewhere. But for the hell of it, it could be measured to
> check what the possible gains are.
>
>
> Steve Bjorg wrote:
>> 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
>>
>
> --
> View this message in context: http://mono.1490590.n4.nabble.com/Faster-tp3402943p3403041.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>