What are some resources I can use to learn profili

Question

I just inherited a C# project that runs way to slow and will have to start optimizing it. What I wanted to do first is learn a little more about profiling/optimizing since I didnt have to do it before. So the question is where do I start, what books/blogs/articels can I read?

I do know OF the .net profilers like ANTS profiler and so on, but I have no idea how to use them efficiently. I have not really used it, just let it run on a few sample apps to play around with the output.

Answer 1

Read Rico Mariani's blog. Before he was promoted, he was a major performance tuning guy for .Net. The older entries in his blog have a ton of good advice. I'd start close to the beginning and work your way forward.

That, plus the articles you've already found (especially the first one) should get you started.

Answer 2

This won't help you much on C#, but the OS X Shark tools (comes with the developer tools from Apple) are the Best profiling tools I've come accross. Almost fun to use!

As to profiling, there's two ways of approach. First, you should understand the software. The data structures especially. Don't start optimizing unless you understand it first.

Second, you shall measure (which seems you're about to do). I've been mislead by my gut instinct almost always; places I would regard as secondary are the time takers. This also means when you're optimizing you're always optimizing for a certain set of test cases you run. The selection of such cases is important.

Answer 3

If you have Visual Studio Team System I suggest using the Profiler it contains.
It is under "Analyze->Profiler"
Using this profiler is really simple. You can just dive in and see what you make of it. Hands on practice is better than any article or book you're going to read about it.

Finding your first couple of bottlenecks is easy as just a few clicks. Solving them might be abit more tricky but again, Optimizing code is just a matter or practice and experience.

Answer 4

You have already hit the nail on the head with the Profiler. All of them, at least all that I have used, follow the same basic methodology. You select the executable and then run the application.

What you do with the output is find the methods that take the most time.l This is not all, but you asked for a good way to learn how to optimize code, so the long running routines are a good place to start. ANTS, which you mentioned, will default to showing long running routines, as will most, if not all, others.

You can exclude the container methods, like Main(), unless you have a lot of code in there (unlikely).

In general, I find most waste in three areas:

1. Loops
2. Recursion
3. Network latency

Area #3, for the database, is generally easy to spot if you will also profile your database, as you will see the number of hits. The best way to reduce network latency, whether database or not (service calls, for example), is to communicate in messages rather than CRUD. Don't query each table, one at a time. Unfortunately, the solution often requires canning parts of many common data layers.

Recursion and loops are very similar problems. If you want bang for the buck, hit the inner loop first.

In .NET, you can also learn a lot about optimization by learning basic IL and examining the IL of your applications through tools like Reflector. A bit of a waste of time, if this is not the major portion of your job description, or something you are likely to want to spend your future career doing. Being a fireman pays well, but being a maintenance only coder can be very boring.

There are only a couple of books on optimizing and profiling .NET applications. The one that has optimzing in the title. The debugging book for .NET has some info on Profiling, but it is not very deep. It is a great book to read for optimization, however, as many issues that cause bugs will also show up in your optimization trips.

Answer 5

There are profilers and performance analysis tools, but while you're trying to find / buy / install / learn one, just try an old-timer's trick...

Run the app under the IDE, and while it's being sluggish, hit the "Pause" button, and ask it what it is doing, and why. The best way to answer this is by reading the call stack.

If it is several times slower than it should be, like 10 times, that means it is spending 90% of its time doing something unnecessary, and that is the probability you will catch it doing it. If you repeat this several times, you can confirm your suspicions with as much accuracy as you want.

So you don't need an expensive / popular but fuzzy magnifying glass.

So finding the reason for the slowness is not the hard part, and there are usually several.

The hard part is, after you've fixed a few "low-hanging-fruits", you will probably have to face the fact that the main reason for the slowness is over-design.

Good luck.

Answer 6

I've used profilers before, they can be helpful, but you can get a lot of help just from creating a singleton stopwatch type class and "Click" it (have it print out the time since the last click and what was just done that took that time) before and after methods you think might be problematic.

If speed is a problem throughout the app, you're probably not going to be able to do too much about it, but you might be able to make a few changes...

Look for inner loops. These are performance death. An inner loop can be caused by something as simple as indexing into a linked list, or doing an insertion sort into an array-based list. (Once I had a list box that was taking 10-20 minutes to fill with tens of thousands of entries, although that's too many entries, the worst part was that it was sorting it by inserting each entry into an array list).

Look for cases where you are doing long operations based on keypresses. These should almost always be done outside the main thread.

Don't even THINK of optimizing things like numbers of classes or how often they are instantiated, string concatenation (outside of loops), nulling out variables or any of the other silly strategies that seem like they should help. I've tried a few and always ended up feeling silly when I actually slowed things down because I wasn't as smart as the runtime is at most things.