Comments on: A Fast Equals() – Remember to Always Measure http://www.ageektrapped.com/blog/a-fast-equals-remember-to-always-measure/ Trapped online since 2004 Wed, 07 Jul 2010 03:23:35 +0000 hourly 1 http://wordpress.org/?v=3.0 By: jason http://www.ageektrapped.com/blog/a-fast-equals-remember-to-always-measure/comment-page-1/#comment-124 jason Fri, 29 Feb 2008 01:33:06 +0000 http://69.42.58.100/~jaso3118/blog/a-fast-equals-remember-to-always-measure/#comment-124 First, empty catch blocks are a scourge. They should just be deleted and the consequences dealt with. Unfortunately, the coder who deleted the useless catch block will be assigned the bug, not the lazy idiot who put it there in the first place. I ran into that today, so it's fresh in my mind. :) Checking for null is probably much faster when you think about it: you're checking references, whereas catching anything requires gathering stack info, creating an exception instance and then throwing it, and then popping the call stack until it's caught and running all the finally blocks. Also, checking for null is such a common occurrence, I suspect MS did something deep down in the CLR to optimize that, not that it needs that much optimizing, it's just checking addresses. I got tired of having all strings be non-null in our app so I did some digging and found that checking an empty string for null and empty is faster that checking it for just empty. Weird,eh? Which leads me to the second thing you're looking for: System.Diagnostics.Stopwatch is what I used to measure Equals(). I ran each class through a loop a million times to get some meaningful numbers. You need to run the test enough for the differences show up, but all the details of all that testing is a beyond the scope of a comment, but not a blog post... First, empty catch blocks are a scourge. They should just be deleted and the consequences dealt with. Unfortunately, the coder who deleted the useless catch block will be assigned the bug, not the lazy idiot who put it there in the first place. I ran into that today, so it’s fresh in my mind. :)

Checking for null is probably much faster when you think about it: you’re checking references, whereas catching anything requires gathering stack info, creating an exception instance and then throwing it, and then popping the call stack until it’s caught and running all the finally blocks.

Also, checking for null is such a common occurrence, I suspect MS did something deep down in the CLR to optimize that, not that it needs that much optimizing, it’s just checking addresses.

I got tired of having all strings be non-null in our app so I did some digging and found that checking an empty string for null and empty is faster that checking it for just empty. Weird,eh?

Which leads me to the second thing you’re looking for: System.Diagnostics.Stopwatch is what I used to measure Equals(). I ran each class through a loop a million times to get some meaningful numbers. You need to run the test enough for the differences show up, but all the details of all that testing is a beyond the scope of a comment, but not a blog post…

]]> By: gfox http://www.ageektrapped.com/blog/a-fast-equals-remember-to-always-measure/comment-page-1/#comment-123 gfox Thu, 28 Feb 2008 22:43:09 +0000 http://69.42.58.100/~jaso3118/blog/a-fast-equals-remember-to-always-measure/#comment-123 So what is the best way to measure? I came across some crappy code in our codebase that seemed to always throw exceptions which were caught with an empty handler. The intent was to use the default behaviour for exceptions. I found that a lower level object was null quite a lot, so instead of the exception handling, I added a test for null. I tried adding some time measurements, but they always returned 0 milliseconds. I used the TimeSpan class and was looking at TotalMilliseconds. Both seemed equally fast, yet I seem to remember reading somewhere that exceptions like this took longer than checking for null (makes sense to me any way). Thoughts? So what is the best way to measure? I came across some crappy code in our codebase that seemed to always throw exceptions which were caught with an empty handler. The intent was to use the default behaviour for exceptions.

I found that a lower level object was null quite a lot, so instead of the exception handling, I added a test for null. I tried adding some time measurements, but they always returned 0 milliseconds.

I used the TimeSpan class and was looking at TotalMilliseconds. Both seemed equally fast, yet I seem to remember reading somewhere that exceptions like this took longer than checking for null (makes sense to me any way).

Thoughts?

]]>