checking input

no it's not. you have a try/catch, which uses extra clock cycles.

since i'm bored outta my mind right now, and to prove the vast difference,

Code:

---

static void Main(string[] args)
        {
            List<int> list = new List<int>();
            int count = 0;
            DateTime start = DateTime.Now;
            for (int i = 0; i < int.MaxValue; ++i)
            {
                try
                {
                    List<int> cast = (List<int>)list;
                    count += cast.Count;
                    ++count;
                }
                catch
                {
                }
            }
            DateTime finish = DateTime.Now;
            Console.WriteLine(finish - start);

            int count2 = 0;
            DateTime start2 = DateTime.Now;
            for (int i = 0; i < int.MaxValue; ++i)
            {
                List<int> cast = list as List<int>;
                if (cast != null)
                {
                    count2 += cast.Count;
                    ++count2;
                }
            }
            DateTime finish2 = DateTime.Now;
            Console.WriteLine(finish2 - start2);
        }

---

here's the output

Code:

---

00:00:03.7344467
00:00:01.2500240

---

using 'as' is 3x faster (under release without a debugger).

Remove the try/catch (and if(!= null) ) and they're equally fast

Well, compiling and running the above I get:
cast: 4.96
as : 2.46

Without the try/get:
cast: 0.83
as : 1.61

Removing the calculations and the check != null for as (so you have only one cast), I get:
cast: 0.83
as : 0.83

So they are the same if you don't have a try/catch. Putting the calculations inside a catch might be unfair, in the sense it will also "try" to catch exceptions for the calculations as well, without a reason.

Finally, without a try/get a cast is 2x faster. So generally I would say if you know what you are doing, like casting a TextBox in an event handler for a TextBox then the cast is faster, because you won't have to try/catch (if the "risk" is acceptable).
Within a try/get they have the same speed

the point of the calculations was to insure that the compiler doesn't optimize, like what happened when you remove the calculations (since the List<int> isn't used for anything, that code is completely removed from the executable, hence, the same speed).

also, the point of the comparison is to have casting with error checking. removing try/catch on the first, or removing != null on the second defeats the purpose.

Code:

---

So they are the same if you don't have a try/catch

---

Code:

---

the cast is faster, because you won't have to try/catch

---

Uh, don't you think you're contradicting yourself here? :)

Anyway, change the declaration of the list to:

Code:

---

object list = new List<int>();

---

and you'll get a huge difference in your results. Now a real cast is made (the compiler probably optimized it before since you're casting from the same type as you're casting to).

wow, that's surprising! changing it to object yields roughly the same time on my machine. stupid compiler doing stupid tricks!

Err, yeah. I am :D. I always do all kind of stupid mistakes when writing in English. Don't know why...

So what is the verdict? The have the same speed inside a try/catch with Magos "fix"?
Outside one?

the verdict from all data we have so far is that doing a cast with error check results in an advantage *sometimes* for the 'as' method, depending on the amount of information the compiler has. i'm actually surprised that whatever optimization that applied to the 'as' was not applied to the ().