Code performance is often an afterthought. Strike that, it’s often not a thought at all. Maybe we’re just getting lazy. I can’t count how many times I’ve seen compilation debug=”true” set on production Web.Configs. It still blows my mind every time. That setting is so adverse to performance Microsoft’s Web.Config template includes a comment reminding the developer to remove it!
Most developers aren’t DBAs, yet still we put (at least some) thought in to indexing our database tables, how we structure their queries, joins, etc… But ask developers why they are using repeatedly rebinding to data when once will do. Why they insist on concatenating 100 strings without using StringBuilder. Or why their code is compiled with full debugging symbols in production. Code benchmark testing and planning just falls by the wayside.
Here’s a simple example demonstrating how some simple configuration changes can have an effect on code performance. So you know, here’s a description of my benchmarking program:
- It handles program warm up to ensure a level starting state
- It runs an isolated, processor-intensive, mathematical test
- It calculates performance based on the median of 10 runs
- All tests were performed with no extraneous processes running, and no debugger attached.
I tested the following cases:
- Project configuration set to “debug” vs “release”
- Building standard code vs. optimized code
- Compilation using JIT vs native image generation.
Here are the results:
|JIT Debug Configuration||JIT Release Configuration||Native Image Generation|
|Standard Code||4,691 ms||3,607 ms||3,598 ms|
|Optimized Code||3,501 ms||3,488 ms||3,448 ms|
Simply checking the “Optimize code” build option in Visual Studio resulted in a 25% increase in performance. Of course, running in release configuration is faster than debug configuration. If you have the need to squeeze out a little more performance, removal of JIT compilation using native image generation also provides a measurable benefit.
I’m sure you’re already familiar with project configurations. Don’t underestimate the power of building under release mode. “Optimize code” has a number of additional advanced options using the compiler command line options for more control. It can cause issues during debugging, and also doesn’t necessarily always speed up your application. So do a little performance testing! Native image generation tends to shave a significant amount off program startup, which didn’t apply here because I warmed up the application before running benchmarking tests. So it may be more significant for cases where an app has frequent cold starts.
Bottom line: Next time you write some code, don’t forget about code performance. Use the System.Diagnostics.Stopwatch class and try some things out… The performance benefit you realize from some simple adjustments might be surprising!
For more information on the options presented here, see:
- Visual Studio – Project Configurations – http://msdn.microsoft.com/en-us/library/wx0123s5(v=vs.71).aspx
- Visual Studio – Optimize code option: http://msdn.microsoft.com/en-us/library/5b4eyb0k(v=vs.100).aspx
- Advanced Compiler – Optimize code options: http://msdn.microsoft.com/en-us/library/k1ack8f1.aspx
- Native Image Generation – http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.80).aspx