Ben Watson et al. - Writing High-Performance .NET Code

Ben Watson

Writing High-Performance .NET Code

Version 2.0

Smashwords Edition

ISBN-13: 978-0-990-58349-3

ISBN-10: 0-990-58349-X

Copyright 2018 Ben Watson

All Rights Reserved. These rights include reproduction, transmission, translation, and electronic storage. For the purposes of Fair Use, brief excerpts of the text are permitted for non-commercial purposes. Code samples may be reproduced on a computer for the purpose of compilation and execution and not for republication.

This eBook is licensed for your personal and professional use only. You may not resell or give this book away to other people. If you wish to give this book to another person, please buy an additional copy for each recipient. If you are reading this book and did not purchase it, or it was not purchased for your use only, then please purchase your own copy. If you wish to purchase this book for your organization, please contact me for licensing information. Thank you for respecting the hard work of this author.

Trademarks

Any trademarked names, logos, or images used in this book are assumed valid trademarks of their respective owners. There is no intention to infringe on the trademark.

Disclaimer

While care has been taking to ensure the information contained in this book is accurate, the author takes no responsibility for your use of the information presented.

Contact

For more information about this book, please visit .

Cover Design

Cover design by Claire Watson, http://www.bluekittycreations.co.uk.

Ben Watson has been a software engineer at Microsoft since 2008. On the Bing platform team, he has built one of the worlds leading .NET-based, high-performance server applications, handling high-volume, low-latency requests across thousands of machines for millions of customers. In his spare time, he enjoys books, music, the outdoors, and spending time with his wife Leticia and children Emma and Matthew. They live near Seattle, Washington, USA.

Thank you to my wife Leticia and our children Emma and Matthew for their patience, love, and support as I spent yet more time away from them to come up with a second edition of this book. Leticia also did significant editing and proofreading and has made the book far more consistent than it otherwise would have been.

Thank you to Claire Watson for doing the beautiful cover art for both book editions.

Thank you to my mentor Mike Magruder who has read this book perhaps more than anyone. He was the technical editor of the first edition and, for the second edition, took time out of his retirement to wade back into the details of .NET.

Thank you to my beta readers who provided invaluable insight into wording, topics, typos, areas I may have missed, and so much more: Abhinav Jain, Mike Magruder, Chad Parry, Brian Rasmussen, and Matt Warren. This book is better because of them.

Thank you to Vance Morrison who read an early version of this and wrote the wonderful Foreword to this edition.

Finally, thank you to all the readers of the first edition, who with their invaluable feedback, have also helped contribute to making the second edition a better book in every way.

by Vance Morrison

Kids these days have no idea how good they have it! At the risk of being branded as an old curmudgeon, I must admit there is more than a kernel of truth in that statement, at least with respect to performance analysis. The most obvious example is that back in my day there werent books like this that capture both the important guiding principles of performance analysis as well as the practical complexities you encounter in real world examples. This book is a gold mine and is worth not just reading, but re-reading as you do performance work.

For over 10 years now, I have been the performance architect for the .NET Runtime. Simply put, my job is to make sure people who use C# and the .NET runtime are happy with the performance of their code. Part of this job is to find places inside the .NET Runtime or its libraries that are inefficient and get them fixed, but that is not the hard part. The hard part is that 90% of the time the performance of applications is not limited by things under the runtimes control (e.g., quality of the code generation, just in time compilation, garbage collection, or class library functionality), but by things under the control of the application developer (e.g., application architecture, data structure selection, algorithm selection, and just plain old bugs). Thus my job is much more about teaching than programming.

So a good portion of my job involves giving talks and writing articles, but mostly acting as a consultant for other teams who want advice about how to make their programs faster. It is in the latter context that I first encountered Ben Watson over 6 years ago. He was that guy on the Bing team who always asked the non-trivial questions (and finds bugs in our code not his). Ben was clearly a performance guy. It is hard to express just how truly rare that is. Probably 80% of all programmers will probably go through most of their career having only the vaguest understanding of the performance of the code they write. Maybe 10% care enough about performance that they learned how to use a performance tool like a profiler at all. The fact that you are reading this book (and this Foreword!) puts you well into the elite 1% that really care about performance and really want to improve it in a systematic way. Ben takes this a number of steps further: He is not only curious about anything having to do with performance, he also cares about it deeply enough that he took the time to lay it out clearly and write this book. He is part of the .0001%. You are learning from the best.

This book is important. I have seen a lot of performance problems in my day, and (as mentioned) 90% of the time the problem is in the application. This means the problem is in your hands to solve. As a preface to some of my talks on performance I often give this analogy: Imagine you have just written 10,000 lines of new code for some application, and you have just gotten it to compile, but you have not run it yet. What would you say is the probability that the code is bug free? Most of my audience quite rightly says zero. Anyone who has programmed knows that there is always a non-trivial amount of time spent running the application and fixing problems before you can have any confidence that the program works properly. Programming is hard, and we only get it right through successive refinement. Okay, now imagine that you spent some time debugging your 10,000-line program and now it (seemingly) works properly. But you also have some rather non-trivial performance goals for your application. What you would say the probability is that it has no performance issues? Programmers are smart, so my audience quickly understands that the likelihood is also close to zero. In the same way that there are plenty of runtime issues that the compiler cant catch, there are plenty of performance issues that normal functional testing cant catch. Thus everyone needs some amount of performance training and that is what this book provides.

Another sad reality about performance is that the hardest problems to fix are the ones that were baked into the application early in its design. That is because that is when the basic representation of the data being manipulated was chosen, and that representation places strong constraints on performance. I have lost count of the number of times people I consult with chose a poor representation (e.g., XML, or JSON, or a database) for data that is critical to the performance of their application. They come to me for help very late in their product cycle hoping for a miracle to fix their performance problem. Of course I help them measure and we usually can find something to fix, but we cant make major gains because that would require changing the basic representation, and that is too expensive and risky to do late in the product cycle. The result is the product is never as fast as it could have been with just a small amount of performance awareness at the right time.