Bob Powell said:
I think that the times type checking is employed at runtime are pretty
infrequent, especially for common cases.
Absolutely not. Almost every time I use a cast, it's for something
which requires an execution time test. The common case is precisely
like the OP's, in my view, and that certainly requires execution time
testing.
I tried the following;
#1 a class cast to an interface
If the class is known to implement the interface at compile-time,
that's redundant. If not, it requires an execution time test.
#2 direct call to the classes implementation
#3 direct call to a class method not used as an interface implementation
#4 call to a derived class cast to a base
No execution time test required here - and no cast required unless
you're trying to affect overloading.
#5 direct call to a derived class method
#6 cast from variable of type object to specific type
And this last one is the important one.
in all cases the compiler worked out the correct info and the IL was
pretty
much the same except for the type of the final object.
To clarify;
#1 object was type a
#2 object was type a
#3 object was type a
#4 object was type aderived
#5 object was of type aderived
#6 object was of type a
The stopwatch times to make 10000 calls to methods that themselves made a
thousand iterations, non optimised, were virtually identical.
While I understand that the circumstance arises occasionally, as a
performance issue, I think the question of casting is a non-starter.
If you're trying to test the cost of casting, why are you also
introducing a method call? I'd also question the value of testing
*redundant* casts - sure, they don't take time at execution time, but
they're also not needed even at compile time.
Here's a test program to *just* test casting as far as possible:
using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;
class Test
{
static void Main(string[] args)
{
int iterations = int.Parse(args[0]);
Stopwatch sw = Stopwatch.StartNew();
for (int i=0; i < iterations; i++)
{
object x = GetSampleObject();
//string x = (string) GetSampleObject();
}
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);
}
[MethodImpl(MethodImplOptions.NoInlining)]
static object GetSampleObject()
{
return "";
}
}
Change which line in the loop is commented out to see the difference
between casting and not. I've explicitly made sure that the
GetSampleObject() method is always called so that the only difference
in the loop should be the cast.
Using 1,000,000,000 iterations, 3 runs for each version:
Without cast: 3403, 3438, 3401
With cast: 3992, 3866, 3904
Is this likely to be significant in most programs? Absolutely not.
However, it does prove that it's not *free*.
The normal time when casts are used are cases like the one the OP
describes, where the cast *is* required because the compiler can't
infer that the conversion is valid - which is precisely the time at
which execution time casts are required. Very occasionally a cast is
required from a more specific type to a more general type in order to
choose the desired overloaded method, but that's not the common case.
Could you describe situations in which you normally cast, and how they
don't require execution time checking? I suspect if you look at the
casts used in genuine (hand-written) code, almost all of them will
require execution time checking.
--
Jon Skeet - <
[email protected]>
Web site:
http://www.pobox.com/~skeet
Blog:
http://www.msmvps.com/jon.skeet
C# in Depth:
http://csharpindepth.com
