Sample Chapter of Writing High-Performance .NET Code, 2nd Edition

Head on over to to read a sample chapter of Writing High-Performance .NET Code, 2nd Edition. The sample PDF also includes some of the front and back material to give you a taste for the rest of the book.

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Writing High-Performance .NET Code on the No Dogma podcast

I was recently interviewed by the wonderful Bryan Hogan for his No Dogma podcast. Check out the episode here. If you want to subscribe, which you should, podcast feed is here. You can follow Bryan or myself on Twitter.

Check it out! We had a great discussion about performance, Bing, Azure, and more.

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Announcing Writing High-Performance .NET Code, 2nd Edition!

The new book will be available for sale on or around May 1, 2018. You can pre-order right now for Kindle in many Amazon markets, and for print as well in the US. 

The book is out! Get it in the US, or go here for more markets and options.

The new book is a mix of greatly expanded coverage of old topics, as well as new material throughout. The fundamentals of .NET and how the GC and JIT work have not changed, not even in the face of .NET Core, but there have been many improvements, new APIs, and new ways of doing things that necessitated some updating and coverage of new topics.

It was also a great opportunity to incorporate a lot of the feedback I’ve received on the first edition.

Here’s a visualization of the book’s structure. I wrote the book in Scrivener and marked each section with a label depending on whether it was unchanged (green), modified (yellow), or completely new (purple). Click to expand to full size.

This is a good overview, but it doesn’t really convey what is exactly “new”–the newness is spread throughout the book in many forms. Here are some highlights:


  • 50% increase in content overall (from 68K words to over 100K words, or over 200 new pages).
  • Fixed all known errata (quite a bit more than on that list, honestly).
  • Incorporated feedback from hundreds of readers.
  • A new foreword by Vance Morrison, .NET Performance Architect at Microsoft.
  • Better-looking graphics.
  • Completely new typesetting system to give a more professional look. (You’ll only notice this in print and PDF formats.)
  • Automated build process that can produce new revisions of all formats much easier than before, allowing me to publish updates as needed.
  • Cut the Windows Phone chapter. (No one will miss this, right?)
  • Updated cover.


  • List of CLR performance improvements over time.
  • Significant increase in examples of using Visual Studio to diagnose CPU usage, heap state, memory allocations, and more, throughout entire book.
  • Introduced a new tool for analyzing .NET processes: Microsoft.Diagnostics.Runtime (“CLR MD”). It’s kind of like having programmatic access to a debugger, and it’s very powerful. I have many examples of its usage throughout the book, tied to specific diagnostic scenarios.
  • Benchmarking! I include actual benchmark results in many sections. Many code samples use a benchmarking library to show the differences in various approaches.
  • More on garbage collection, including advanced configuration options; reworked and more detailed explanations of the GC process including less-known information; discussion of recent libraries to help with pooling; examples of using weak references; object resurrection; stackalloc; more on finalization; more ways to diagnose problems; and much, much more. This was already the biggest chapter, and it got bigger.
  • More details about JIT, how to do custom warmup, how to figure out which code is jitted, and many more improvements.
  • Greatly expanded coverage of TPL, including the TPL Dataflow library, how to use tasks effectively, avoiding lock convoys, and many other smaller improvements to existing topics.
  • More guidance on struct and class design, such as immutability, thread safety, and more. When to use tuples, the new ValueTuple type.
  • Ref-returns and locals and when to use.
  • Much more content on collections, including effectively taking advantage of initial capacity; sorting; key comparisons; jagged vs. multi-dimensional arrays; analyzing the performance of various collection types; and more.
  • Discussion of SIMD commands, including examples and benchmarks.
  • A detailed analysis of LINQ and why it’s more expensive than you think.
  • More ways to consume and process ETW events.
  • A detailed example of building a Roslyn-style Code Analyzer and automatic fixer (FxCop replacement).
  • A new appendix with high-level tips for ADO.NET, ASP.NET, and WPF.
  • And a lot more…

See the book’s web-site for up-to-date details on where to buy, and other news.

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Don’t Make This Dumb Locking Mistake

What’s wrong with this code:

    if (!Monitor.TryEnter(this.lockObj))

This is a rookie mistake, but sadly I made it the other day when I was fixing a bug in haste. The problem is that the Monitor.Exit in the finally block will try to exit the lock, even if the lock was never taken. This will cause an exception. Use a different TryEnter overload instead:

bool lockTaken = false;
    Monitor.TryEnter(this.lockObj, ref lockTaken))
    if (!lockTaken)
    if (lockTaken)

You might be tempted to use the same TryEnter overload we used before and rely on the return value to set lockTaken. That might be fine in this case, but it’s better to use the version shown here. It guarantees that lockTaken is always set, even in cases where an exception is thrown, in which case it will be set to false.

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Free Kindle version of Writing High-Performance .NET Code when you buy the print version

BookCover -ThumbAs of last week, when you buy the print version of Writing High-Performance .NET Code from Amazon, you can get the Kindle version for free.

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Get Your Thread Synchronization Right the First Time

I was recently debugging a problem that just didn’t make any sense at first.

The code looked like this:

class App
    public bool IsRunning {get; set;}
    private Thread houseKeepingThread;
    public void Start()
        this.IsRunning = true;
        this.houseKeepingThread = new Thread(ThreadFunc);
    private void ThreadFunc()
        while (this.IsRunning)
            // wait for 30 seconds

The actual code was of course a bit more complicated, but this demonstrates the essence of the problem.

The outward manifestation of the bug was that there was evidence that DoWork wasn’t being called over time as it should have.

To debug this, I first concentrated on reasons that the thread could end early, and none of them made any sense.

To finally figure it out, I attached a debugger to a process known to be in a suspect state and discovered evidence in the state of the App object that DoWork had never run, not even once.

I stared at the code for five seconds and then said out loud: “IsRunning isn’t volatile!”

Despite setting IsRunning to true before starting the thread, it is completely possible that the thread starts running before the memory is coherent across all of the threads.

What’s amazing about this bug is that it existed from the very beginning of this application. As in checkin #1. It has probably been causing problems for a while at some low level, but it recently must have gotten worse—it could be for any reason, some change in the pattern of execution, the load on the system, who knows.

The fix was quite easy:

Make a volatile backing field for the IsRunning property.

By using volatile, there will be a memory barrier that will enforce coherency across all threads that access this variable. Problem solved.

The lesson here isn’t about any particular debugging skills. The real lesson is to make sure you get this right in the first place, because debugging it takes far longer and is much trickier than just reasoning about it in the first place. These types of problems can stay hidden and extremely rare for a very long time until some other innocuous change causes them to start manifesting in strange, seemingly impossible ways.

If you want to learn more about memory barriers and when they’re required, you can check out Chapter 4 of Writing High-Performance .NET Code, and there is also this tutorial by Joseph Albahari.

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Announcing Microsoft.IO.RecycableMemoryStream

It is with great pleasure that I announce the latest open source release from Microsoft. This time it’s coming from Bing.

Before explaining what it is and how it works, I have to mention that nearly all of the work for actually getting this setup on GitHub and preparing it for public release was done by by Chip Locke [Twitter | Blog], one of our superstars.

What It Is

Microsoft.IO.RecyclableMemoryStream is a MemoryStream replacement that offers superior behavior for performance-critical systems. In particular it is optimized to do the following:

  • Eliminate Large Object Heap allocations by using pooled buffers
  • Incur far fewer gen 2 GCs, and spend far less time paused due to GC
  • Avoid memory leaks by having a bounded pool size
  • Avoid memory fragmentation
  • Provide excellent debuggability
  • Provide metrics for performance tracking

In my book Writing High-Performance .NET Code, I had this anecdote:

In one application that suffered from too many LOH allocations, we discovered that if we pooled a single type of object, we could eliminate 99% of all problems with the LOH. This was MemoryStream, which we used for serialization and transmitting bits over the network. The actual implementation is more complex than just keeping a queue of MemoryStream objects because of the need to avoid fragmentation, but conceptually, that is exactly what it is. Every time a MemoryStream object was disposed, it was put back in the pool for reuse.

-Writing High-Performance .NET Code, p. 65

The exact code that I’m talking about is what is being released.

How It Works

Here are some more details about the features:

  • A drop-in replacement for System.IO.MemoryStream. It has exactly the same semantics, as close as possible.
  • Rather than pooling the streams themselves, the underlying buffers are pooled. This allows you to use the simple Dispose pattern to release the buffers back to the pool, as well as detect invalid usage patterns (such as reusing a stream after it’s been disposed).
  • Completely thread-safe. That is, the MemoryManager is thread safe. Streams themselves are inherently NOT thread safe.
  • Each stream can be tagged with an identifying string that is used in logging. This can help you find bugs and memory leaks in your code relating to incorrect pool use.
  • Debug features like recording the call stack of the stream allocation to track down pool leaks
  • Maximum free pool size to handle spikes in usage without using too much memory.
  • Flexible and adjustable limits to the pooling algorithm.
  • Metrics tracking and events so that you can see the impact on the system.
  • Multiple internal pools: a default “small” buffer (default of 128 KB) and additional, “large” pools (default: in 1 MB chunks). The pools look kind of like this:


In normal operation, only the small pool is used. The stream abstracts away the use of multiple buffers for you. This makes the memory use extremely efficient (much better than MemoryStream’s default doubling of capacity).

The large pool is only used when you need a contiguous byte[] buffer, via a call to GetBuffer or (let’s hope not) ToArray. When this happens, the buffers belonging to the small pool are released and replaced with a single buffer at least as large as what was requested. The size of the objects in the large pool are completely configurable, but if a buffer greater than the maximum size is requested then one will be created (it just won’t be pooled upon Dispose).


You can jump right in with no fuss by just doing a simple replacement of MemoryStream with something like this:

var sourceBuffer = new byte[]{0,1,2,3,4,5,6,7}; 
var manager = new RecyclableMemoryStreamManager(); 
using (var stream = manager.GetStream()) 
    stream.Write(sourceBuffer, 0, sourceBuffer.Length); 

Note that RecyclableMemoryStreamManager should be declared once and it will live for the entire process–this is the pool. It is perfectly fine to use multiple pools if you desire.

To facilitate easier debugging, you can optionally provide a string tag, which serves as a human-readable identifier for the stream. In practice, I’ve usually used something like “ClassName.MethodName” for this, but it can be whatever you want. Each stream also has a GUID to provide absolute identity if needed, but the tag is usually sufficient.

using (var stream = manager.GetStream("Program.Main"))
    stream.Write(sourceBuffer, 0, sourceBuffer.Length);

You can also provide an existing buffer. It’s important to note that this buffer will be copied into the pooled buffer:

var stream = manager.GetStream("Program.Main", sourceBuffer, 
                                    0, sourceBuffer.Length);

You can also change the parameters of the pool itself:

int blockSize = 1024;
int largeBufferMultiple = 1024 * 1024;
int maxBufferSize = 16 * largeBufferMultiple;

var manager = new RecyclableMemoryStreamManager(blockSize, 

manager.GenerateCallStacks = true;
manager.AggressiveBufferReturn = true;
manager.MaximumFreeLargePoolBytes = maxBufferSize * 4;
manager.MaximumFreeSmallPoolBytes = 100 * blockSize;

Is this library for everybody? No, definitely not. This library was designed with some specific performance characteristics in mind. Most applications probably don’t need those. However, if they do, then this library can absolutely help reduce the impact of GC on your software.

Let us know what you think! If you find bugs or want to improve it in some way, then dive right into the code on GitHub.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

2014 Year In Review

Just a recap of the things that have occurred this year. I have been truly blessed, and I have lot to be thankful for. Just a small part of them here…

Writing High-Performance .NET Code was published!

BookCover -Thumb

I spent the first half of the year heads down and working on the book until it was finally published in mid-July.

Since then, I have been amazed at the positive response it has gotten. For more information, you can read more at the book’s site.

One choice review: “It’s engaging, and reads like a technical memoirs of the lessons learned from the genesis of a very large scale .NET service. Readability is great, but the technical content is invaluable…. I personally felt that the chapter on GC alone is easily worth the price of the book and the time to read it….it’s an excellent resource to fully understand what you need to know about GC…. This book does a very good job and breaking down the myths of poor performing managed code, and the optimal strengths managed code has over native…. I gave this book 5 stars for several reasons. First, it delivers on the content and readability the book is selling. The price is also very generous for the content you’re getting.” 5 stars – I. Paradiso

6 Years at Microsoft

I hit 6 years at Microsoft, all in Bing. Still loving it. Google and Facebook seem to get all the press these days, but Microsoft is a truly amazing place to work and I’m looking forward to many more years of great work.

In-Depth Technical Articles

Blog Entries

Some of the highlights of 2014:

Road Trip!

We drove down to northern California and spent a few days among the redwoods forests. Truly amazing.


Looking forward to 2015

There is a lot to look forward to in 2015. I’ll continue to blog. My book should see some new international developments that I’m excited about. More road trips are in order… Things on my list to visit with family around the PNW:

  • Mt. St. Helens
  • Leavenworth
  • Cascade loop
  • The Olympics
  • Oregon Coast

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Buy EPUB and PDF of Writing High-Performance .NET Code and Save 25%

My book Writing High-Performance .NET Code is already pretty inexpensive by programming book standards, but I’ve added a new deal. If you want to do get both the PDF and the EPUB, you can get 25% off the entire order, which basically makes one of them over 50% off.

Just go to, add both formats to your shopping cart, and use the 25PERCENT discount code at checkout to receive the discount.

Update: The discount code wasn’t working reliably, so I’ve just added a third buying option that is a bundle of the two formats.

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order: