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
I'm taking an undergraduate course (one topic is Performance Analysis) and the recommended text is The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling. It's something of a bible on the subject and might be a bit overkill.
these two articles is all I found till now:
Find Application Bottlenecks with Visual Studio Profiler
Measuring .NET Application Performance
If you are familiar with and have already purchased ANTS (a very fine profiler) then go here for a quick tutorial to get you up and running.
I would download a few of the profiling tools available (free trials) and start using them.
I used jetbrains , and there are others. (ants for example, devpartner and a MS one?, atomatedqa, etc) You should not have too much problems running them. They have reports that give you lots of information and you can learn pretty quickly just using the applications.
Any one of them will probably help you and it is nice to use the trials. You can then either just shelve the decision to buy the tool, or buy the one(s) that was the most helpful/easiest to use. In general they are great time savers and worth the money, though some can be expensive. (I have a hard time with the ones on the upper end when there are very good tools for a lot less money)
You might find some serious/major performance issues the first day you install and run them. I know I did.
good luck.
just download some tools and start running your app.
EDIT:
As for books and learning - basically the best way to learn about problems with code is to find bad code. Many times doing inspections with experienced developers will be helpful.
as an example: I think Joel wrote an article way back about he did something like
for (int i = 0; i < strlen(some string); i++)
that is pretty obvious that you are going to call strlen (expensive) every iteration of the loop.
You'll have to look at some of the code after the profiler tells you where time is being spent and see if the code can be fixed easily with simple things like that, or changes have to be made in the design of the algorithms.
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.
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.