checking input

This is a discussion on checking input within the C# Programming forums, part of the General Programming Boards category; no it's not. you have a try/catch, which uses extra clock cycles....

  1. #16
    Registered User
    Join Date
    Aug 2008
    Posts
    188
    no it's not. you have a try/catch, which uses extra clock cycles.

  2. #17
    Registered User
    Join Date
    Aug 2008
    Posts
    188
    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).

  3. #18
    Confused Magos's Avatar
    Join Date
    Sep 2001
    Location
    Sweden
    Posts
    3,145
    Remove the try/catch (and if(!= null) ) and they're equally fast
    MagosX.com

    Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime.

  4. #19
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    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

  5. #20
    Registered User
    Join Date
    Aug 2008
    Posts
    188
    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.

  6. #21
    Confused Magos's Avatar
    Join Date
    Sep 2001
    Location
    Sweden
    Posts
    3,145
    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).
    MagosX.com

    Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime.

  7. #22
    Registered User
    Join Date
    Aug 2008
    Posts
    188
    wow, that's surprising! changing it to object yields roughly the same time on my machine. stupid compiler doing stupid tricks!

  8. #23
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    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?

  9. #24
    Registered User
    Join Date
    Aug 2008
    Posts
    188
    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 ().

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. About aes
    By gumit in forum C Programming
    Replies: 13
    Last Post: 10-24-2006, 04:42 PM
  2. Checking input
    By Unregistered in forum C Programming
    Replies: 1
    Last Post: 05-26-2002, 04:06 AM
  3. Checking input
    By Unregistered in forum C Programming
    Replies: 3
    Last Post: 05-10-2002, 10:00 AM
  4. checking if input is a number ?
    By Unregistered in forum C++ Programming
    Replies: 2
    Last Post: 12-06-2001, 09:07 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21