I saw Jacob Cynamon speak at the local .NET user's group last night. He presents well and has a cool name. His topic was general performace tuning for the .net framework. Having gone through an "oh no perforance sucks" experience on a large ASP.NET project and an almost as large compact framework project already this year, this topic was of some interest to me; I wanted to see if I'd missed anything major.

The presentation was good, but it did look like I've hit the major points in my own optimization efforts. I wanted to add my own points to two of Jacob's: the cost of boxing and the cost of throwing exceptions.

Everyone talks about how expensive boxing is as if it's like downloading a 5 meg file over a 14400baud modem. Until last night I had not thought about exactly why boxing is so expensive or how expensive it is compared to other operations. Jacob's initial example showed value type assignment, compared to value type to object and object to value type. The boxing operation took about 13 times as long as assigning a value type. The first impression might be "See, boxing is the devil, we told you so". What could make it so expensive an operation? If I were implementing it I would create a container object to hold the value type and return it when asked. The cost would just be the creation of an object on the heap and maybe a tiny bit of relfection.

After the presentation was over I asked if he could throw a fourth comparison in there: object o = new object();. Sure enough, just calling "new()" took 99% as long as the boxing operation. What's my point? Yes, boxing is expensive compared to just using value types. Run CLR profiler once and see how many objects are created and garbage collected during a mundane operation we take for granted in .NET, like calling a web service. Boxing will be pretty low on my list of things to look for next time I need to squeeze performance out of an application.

The next item I wanted to add to was throwing exceptions. I read a statistic on MSDN somewhere (I can't find the link now) that claimed throwing an exception slowed down the executing thread by a factor of six, or something like that. This makes some sense, in terms of the op codes that would need to be executed to suddenly break execution a lot of things would need to happen: doing a "goto" and running Dispose methods for using and try/finally blocks can't be cheap.

My thought regarding exceptions was similar to my thought on boxing. You should only use exceptions for exceptional situations, not to control program flow. This is not a new tip, I read it first in one of Bjarne Stroustrup's books on the language he invented. Many developers may not be aware of how many exceptions the .NET class libraries are throwing and subsequently swallowing. You'll never see these exceptions unless you run your app in the debugger, and set all CLR exceptions to break into the debugger whether or not they are handled. You might be surprised how many times security violation exceptions are thrown while trying to read resource files, or to know that VB methods like CanParse or IsDate function by just trying to Parse and catching the FormatException if the operation fails. Depending on what functions your app is calling you may be suffering from hundreds or thousands of swallowed exceptions, especially at the time your app starts up. Matt Terski gave another good example in that every time you call Response.Redirect("foo") in ASP.NET a ThreadAbortedException is thrown. Check those First Chance excpetions!