Practical Performance Profiling: Improving the Efficiency of .NET Code [Paperback]

My acquisition of this book came at a good time. I was beginning to learn how to best profile the latest version of a .NET library our team has been working on. The library is a core component in a high profile system. It is used tens of thousands of times per day; and very frequently within peak hours.

Why do we need to profile this component?

The main benefit we hoped to gain was a reduced average run time: with this type of component, any performance gain is a win. Additionally we have an opportunity to improve code quality: even though this is relatively mature code, mistakes can happen. Database queries can be optimised. Edge cases can be mitigated. Lastly improving performance improves usage efficiency of server resources, which is important in any organisation.

The use of a profiler is essential. It is impossible for a developer to manually detect all performance issues within a given component. There are numerous factors including interactions within and outside the component. These include database query performance, I/O latency, network latency, and application server limitations. Using a profiler provides us with a large amount of statistical data, as well as a visualisation mechanism with which to analyse the data.

Here's the thing about performance profilers, though. They are easy to run against your application and get a whole LOT of results. Most profilers provide a sort of inline guidance, i.e. showing you the lines of code which consume the most time. So some may think that this is all you need: find the worst performing lines of code, make them more efficient, done. But this is only part of the picture. What about making sure code is kept maintainable? Understanding what a profiler's results are really telling you is not immediately obvious to someone who is inexperienced, and the analysis and correction are the most important (and fun) parts of the exercise.

You also need a defined strategy when profiling. In other words, you need a way to prioritise the changes, and a way to measure the improvement you make.

So this is why a good book on the topic is very useful. Yes, there are thousands of blog posts available on this topic, but there is something to be said for the conciseness and completeness achieved in a book written by a competent author.

At first look, I could see this book is a very thorough exploration of .NET performance profiling - weighing in at 551 pages!

I appreciated the first chapter, which maps out generic profiling principles and guidelines, regardless of language/profiling tool. As mentioned, if you don't have a strategy before you start profiling, you will waste time just diving into the profiler results and trying to fix the first issue you see. Likewise, chapter 2 provides low level details regarding the effect of design decisions and system limitations on performance. This is brilliant if you have done a first pass of improvements and wish to further boost your application's performance.

Chapter 4 assesses three leading profiling tools. Of course, the ANTS Performance Profiler is included, as well as JetBrains dotTrace, and Eqatec Profiler. This section will quickly become out of date, however it is still useful, since you can use the criteria listed to assess future versions of tools, and other tools.

Where this book really helped us was in the demonstration of how to profile the sample application, PROFI, in chapters 5 and 6. Note: the code is in C#. This is the most efficient way to learn how to profile and analyse results. The app is a good choice because it comprises a client/server architecture and makes use of web services. This is a common scenario, so should benefit most readers.

The author takes you through the entire process from setting up the application and profiler to iterating through analysis and optimisation attempts. He includes some good advice on strategy - namely, don't just immediately work on the hotspots recommended by the profiler - prioritise based on real-world performance gain. In other words, optimise the most used parts of the application, not necessarily the worst performing. These two chapters contains many examples of code issues accompanied by analysis and rectification, and are the best parts of the book. It even includes details about how to run an automated load test on the server while profiling, and how to analyse the results.

Chapter 7: Beyond Profiling was very interesting because it delves into actual vs perceived performance. In other words, how responsive does the application performance "feel" to the user, regardless of actual duration to complete workloads. These days, with so many distributed systems providing data and processing, asynchronous operations are essential. I thought this chapter was useful in covering several ways to improve perceived performance.

Overall, as hoped, this book provides a clear method for profiling .NET applications with a lot of practical examples. It is also a very in-depth book, with a lot of time spent explaining many aspects of performance profiling .NET. As such, it will definitely suit a reader who wants to have a very deep understanding of the topic. If you are in a hurry and need something more concise then I would suggest focussing on chapters 1, 5, 6, and 8 (the checklist is very handy as a fast way to remove common performance issues) and read the remaining chapters when you have time. They are well worth it.

I received a free copy of this book at a conference and as I do quite a bit of performance work, I was very interested in learning new tricks. Unfortunately the number of errors and omissions in the current edition of this book are alarming. Just to name a few:

- The author argues that as long as response times are below 3 seconds, everything is fine. Imagine a text editor with a 3 sec delay on every keystroke or a game running at 1/3 FPS. Clearly there are scenarios where this is not good enough.

- The author recommends doing all performance measurements on debug builds. Debug builds aren't optimized, so this doesn't make any sense.

- A lot of time is spent talking about inlining at the IL level and all the code samples are clearly from debug builds. Inlining doesn't happen at the IL level and no inlining is done for debug builds. The text doesn't make it very clear that the IL actually never executes as is. The fact that IL is compiled to native code is not really discussed.

- The GC is described as completely unpredictable whereas in fact the overall behavior is actually well documented. Several incorrect statements are made about the GC as well, e.g. the author claims that the GC will spin up a new (low priority) thread to do a collect. Spinning up a new thread can be orders of magnitude more expensive than doing a gen0 or gen1 collect, so doing so would be a really bad idea.

- Despite the recent publication date, the book doesn't cover how async and parallel code can be used to improve performance.

- The section on how Windows handles memory is completely wrong. The author seems to believe that applications allocate RAM directly. There's no discussion of the OS memory manager. The concept of address space isn't even mentioned.

FWIW I have forwarded a list of comments to the publisher and I can only hope that future revisions of the book will be more accurate. In the meantime I recommend getting Pro .NET Performance: Optimize Your C# Applications (Professional Apress) instead.