P
Pavel Minaev
There was an earlier discussion regarding which one is faster - a
throwing cast - "(Foo)obj", or a non-throwing one - "obj as Foo", when
both are available for a given type and value. The consensus was that,
since a check has to be made by the compiler in either case, the speed
should be equivalent in case object is indeed of a requested type.
Sounds perfectly reasonable, but I've spotted the following in
the .NET source code (from MS symbol servers) today, in file
BindingList.cs, method Child_PropertyChanged:
// The change event is broken should someone pass
an item to us that is not
// of type T. Still, if they do so, detect it and
ignore. It is an incorrect
// and rare enough occurrence that we do not want
to slow the mainline path
// with "is" checks.
T item;
try {
item = (T)sender;
}
catch(InvalidCastException) {
ResetBindings();
return;
}
Now this gets interesting, since the comment clearly implies that a
throwing cast is, after all, faster than a check for the non-throw
case (and since "is" and "as" are both compiled to "isinst" IL, we
know that it is really about "castclass" vs "isinst"). I wonder how
true this really is, and if so, why is it the case. I'm going to play
with debugger to see what the JIT produces in either case later, but
perhaps someone already knows the reason?
throwing cast - "(Foo)obj", or a non-throwing one - "obj as Foo", when
both are available for a given type and value. The consensus was that,
since a check has to be made by the compiler in either case, the speed
should be equivalent in case object is indeed of a requested type.
Sounds perfectly reasonable, but I've spotted the following in
the .NET source code (from MS symbol servers) today, in file
BindingList.cs, method Child_PropertyChanged:
// The change event is broken should someone pass
an item to us that is not
// of type T. Still, if they do so, detect it and
ignore. It is an incorrect
// and rare enough occurrence that we do not want
to slow the mainline path
// with "is" checks.
T item;
try {
item = (T)sender;
}
catch(InvalidCastException) {
ResetBindings();
return;
}
Now this gets interesting, since the comment clearly implies that a
throwing cast is, after all, faster than a check for the non-throw
case (and since "is" and "as" are both compiled to "isinst" IL, we
know that it is really about "castclass" vs "isinst"). I wonder how
true this really is, and if so, why is it the case. I'm going to play
with debugger to see what the JIT produces in either case later, but
perhaps someone already knows the reason?