Optimization Advice
Brian Noyes has some great advice on optimization. It's nothing earthshaking, but bears repeating: those couple of extra instructions are very likely not the reason your app's a dog. Don't guess, profile. On top of that, platform level profiling is hard. We've been going through this excercise at work, and it's been contentious and embarrassing for some people who've recommended some micro-optimizations that have ended up not showing any improvement (and sometimes negative improvement) when tested at the system level. The rule is profile first, then use that evidence to guide you. However, profiling in the traditional sense isn't enough for applications spread among multiple machines, where you need to factor in network usage, the impacts of a load balancer, etc. In addition, the behavior of your application can surprise you under high load, and a traditional profile is much too invasive in this situation; we've ended up doing our own instrumentation to get measurements without affecting performance too much. Incidentally, the article that Peter Provost referenced the other day has an appendix that covers monitoring the ASP.NET thread pool with custom performance counters; if you're doing .NET web applications, you'll most likely want to monitor this information. If the ASP.NET worker process runs out of threads, you'll run into an unexpected bottleneck that can take a while to understand. This really should be one of the built-in counters, but it isn't, for some reason.