Thread: 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).

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.

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 . 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 ().