Tips for optimizing C#/.NET programs

Question

It seems like optimization is a lost art these days. Wasn't there a time when all programmers squeezed every ounce of efficiency from their code? Often doing so while walking 5 miles in the snow?

In the spirit of bringing back a lost art, what are some tips that you know of for simple (or perhaps complex) changes to optimize C#/.NET code? Since it's such a broad thing that depends on what one is trying to accomplish it'd help to provide context with your tip. For instance:

• When concatenating many strings together use StringBuilder instead. See link at the bottom for caveats on this.
• Use string.Compare to compare 2 strings instead of doing something like string1.ToLower() == string2.ToLower()

The general consensus so far seems to be measuring is key. This kind of misses the point: measuring doesn't tell you what's wrong, or what to do about it if you run into a bottle neck. I ran into the string concatenation bottle neck once and had no idea what to do about it, so these tips are useful.

My point for even posting this is to have a place for common bottle necks and how they can be avoided before even running into them. It's not even necessarily about plug and play code that anyone should blindly follow, but more about gaining an understanding that performance should be thought about, at least somewhat, and that there's some common pitfalls to look out for.

I can see though that it might be useful to also know why a tip is useful and where it should be applied. For the StringBuilder tip I found the help I did long ago at here on Jon Skeet's site.

Answer 1

Get a good profiler.

Don't bother even trying to optimize C# (really, any code) without a good profiler. It actually helps dramatically to have both a sampling and a tracing profiler on hand.

Without a good profiler, you're likely to create false optimizations, and, most importantly, optimize routines that aren't a performance problem in the first place.

The first three steps to profiling should always be 1) Measure, 2) measure, and then 3) measure....

Answer 2

Well, the easiest optimization you can make is by enabling code optimization for the projects being compiled. Right-click the project name in Visual Studio, click "Build" on the left side of the project options tab, and check "Optimize code" at the bottom of the "General" options group.

Answer 3

People have funny ideas about what actually matters. SO is full of questions about, for example, is ++i more "performant" than i++. Here's an example of real performance tuning, and it's basically the same procedure for any language. If code is simply written a certain way "because it's faster", that's guessing.

Sure, you don't purposely write stupid code, but if guessing worked, there would be no need for profilers and profiling techniques.

Answer 4

• Don't use Magic Numbers, use Enumerations
• Don't hard-code values
• Use generics where possible since it's typesafe & avoids boxing & unboxing
• Use error handler where it's absolutely needed
• Dispose, Dispose, Dispose. CLR wound't know how to close your db connections, so close them after use & dispose of unmanaged resources
• Use common-sense !

Answer 5

The truth is that there is no such thing as the perfect optimised code. You can, however, optimise for a specific portion of code, on a known system (or set of systems) on a known CPU type (and count), a known platform (MS? Mono?), a known framework / BCL version, a known CLI version, a known compiler version (bugs, spec changes, tweaks), a known amount of total and available memory, a known assembly origin (GAC? disk? remote?), with known background system activity from other processes.

In the real world, use a profiler, and looks at the important bits; usually the obvious things are anything involving IO, anything involving threading (again, this changes hugely between versions), and anything involving loops and lookups, but you might be surprised at what "obviously bad" code isn't actually a problem, and what "obviously good" code is a huge culprit.

Answer 6

When working with ORMs be aware of N+1 Selects.

List<Order> _orders = _repository.GetOrders(DateTime.Now);
foreach(var order in _orders)
{
    Print(order.Customer.Name);
}

If the customers are not eagerly loaded this could result in several round trips to the database.

Answer 7

It seems like optimization is a lost art these days.

There was once a day when manufacture of, say, microscopes was practiced as an art. The optical principles were poorly understood. There was no standarization of parts. The tubes and gears and lenses had to be made by hand, by highly skilled workers.

These days microscopes are produced as an engineering discipline. The underlying principles of physics are extremely well understood, off-the-shelf parts are widely available, and microscope-building engineers can make informed choices as to how to best optimize their instrument to the tasks it is designed to perform.

That performance analysis is a "lost art" is a very, very good thing. That art was practiced as an art. Optimization should be approached for what it is: an engineering problem solvable through careful application of solid engineering principles.

I have been asked dozens of times over the years for my list of "tips and tricks" that people can use to optimize their vbscript / their jscript / their active server pages / their VB / their C# code. I always resist this. Emphasizing "tips and tricks" is exactly the wrong way to approach performance. That way leads to code which is hard to understand, hard to reason about, hard to maintain, that is typically not noticably faster than the corresponding straightforward code.

The right way to approach performance is to approach it as an engineering problem like any other problem:

• Set meaningful, measurable, customer-focused goals.
• Build test suites to test your performance against these goals under realistic but controlled and repeatable conditions.
• If those suites show that you are not meeting your goals, use tools such as profilers to figure out why.
• Optimize the heck out of what the profiler identifies as the worst-performing subsystem. Keep profiling on every change so that you clearly understand the performance impact of each.
• Repeat until one of three things happens (1) you meet your goals and ship the software, (2) you revise your goals downwards to something you can achieve, or (3) your project is cancelled because you could not meet your goals.

This is the same as you'd solve any other engineering problem, like adding a feature -- set customer focused goals for the feature, track progress on making a solid implementation, fix problems as you find them through careful debugging analysis, keep iterating until you ship or fail. Performance is a feature.

Performance analysis on complex modern systems requires discipline and focus on solid engineering principles, not on a bag full of tricks that are narrowly applicable to trivial or unrealistic situations. I have never once solved a real-world performance problem through application of tips and tricks.

Answer 8

Tell the compiler what to do, not how to do it. As an example, foreach (var item in list) is better than for (int i = 0; i < list.Count; i++) and m = list.Max(i => i.value); is better than list.Sort(i => i.value); m = list[list.Count - 1];.

By telling the system what you want to do it can figure out the best way to do it. LINQ is good because its results aren't computed until you need them. If you only ever use the first result, it doesn't have to compute the rest.

Ultimately (and this applies to all programming) minimize loops and minimize what you do in loops. Even more important is to minimize the number of loops inside your loops. What's the difference between an O(n) algorithm and an O(n^2) algorithm? The O(n^2) algorithm has a loop inside of a loop.

Answer 9

Always verify that your large objects are finalized at least in a few next garbage collections. Memory leaks are very easy to introduce (especially when working with data templates in WPF) and hard to detect with standard tools like SOS.DLL etc. Frankly, the big GC button in the about window doesn't seem like something wild to me.

Answer 10

Optimization guidelines:

1. Don't do it unless you need to
2. Don't do it if it's cheaper to throw new hardware at the problem instead of a developer
3. Don't do it unless you can measure the changes in a production-equivalent environment
4. Don't do it unless you know how to use a CPU and a Memory profiler
5. Don't do it if it's going to make your code unreadable or unmaintainable

As processors continue to get faster the main bottleneck in most applications isn't CPU, it's bandwidth: bandwidth to off-chip memory, bandwidth to disk and bandwidth to net.

Start at the far end: use YSlow to see why your web site is slow for end-users, then move back and fix you database accesses to be not too wide (columns) and not too deep (rows).

In the very rare cases where it's worth doing anything to optimize CPU usage be careful that you aren't negatively impacting memory usage: I've seen 'optimizations' where developers have tried to use memory to cache results to save CPU cycles. The net effect was to reduce the available memory to cache pages and database results which made the application run far slower! (See rule about measuring.)

I've also seen cases where a 'dumb' un-optimized algorithm has beaten a 'clever' optimized algorithm. Never underestimate how good compiler-writers and chip-designers have become at turning 'inefficient' looping code into super efficient code that can run entirely in on-chip memory with pipelining. Your 'clever' tree-based algorithm with an unwrapped inner loop counting backwards that you thought was 'efficient' can be beaten simply because it failed to stay in on-chip memory during execution. (See rule about measuring.)

Answer 11

OK, gotta throw in my favorite: If the task is long enough for human interaction, use a manual Break in the debugger.

Vs. a profiler, this gives you a call stack and variable values you can use to really understand what's going on.

Do this 10-20 times and you get a good idea of what optimization might really make a difference.

Answer 12

I don't really try to optimize my code but at times I will go through and use something like reflector to put my programs back to source. It is interesting to then compare what I wrong with what the reflector will output. Sometimes I find that what I did in a more complicated form was simplified. May not optimize things but helps me to see simpler solutions to problems.