Improving .NET Application Performance and Scalability

I'm happy to announce that the Patterns and Practices group has made the release version of  "Improving .NET Application Performance and Scalability" available at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenet.asp

The team asked me to write an foreword for their guide and I include that here by way of introduction and recommendation.  It was my pleasure to contribute to this work and I hope you will both enjoy and learn from it.

-----

Foreword

I’m giving up my official job title because it’s clear to me now that, despite the incidental bits of code that I write, what I actually do is better described by the words “Performance Preacher,” and I may as well embrace reality.

It’s not so bad really.

Now the thing about being a preacher is that you have to be able to regularly come up with simple yet clever rules to get the attention of your flock. And of course you don’t want to turn your flock into a mindless cult of zombies, even if it seems like that might be convenient on certain days. No, the truth is that a good preacher will be providing resources, guidance, a good example or two, and most important of all, a framework of values.

And here we come to the topic at hand. What are good values for performance work? Well, to start with you need to know a basic truth. Software is in many ways like other complex systems: There’s a tendency toward increasing entropy. It isn’t anyone’s fault; it’s just the statistical reality. There are just so many more messed-up states that the system could be in than there are good states that you’re bound to head for one of the messed-up ones. Making sure that doesn’t happen is what great engineering is all about.

Now, it’s time for the simple yet clever rule: Never give up your performance accidentally.

That sums it up for me, really. I have used other axioms in the past - rules such as making sure you measure, making sure you understand your application and how it interacts with your system, and making sure you’re giving your customers a “good deal.” Those are all still good notions, but it all comes down to this: Most factors will tend to inexorably erode your performance, and only the greatest vigilance will keep those forces under control.

If you fail to be diligent, you can expect all manner of accidents to reduce your system’s performance to mediocre at best, and more likely to something downright unusable. If you fail to use discipline, you can expect to spend hours or days tuning aspects of your system that don't really need tuning, and you will finally conclude that all such efforts are “premature optimizations” and are indeed "the root of all evil."[1]  You must avoid both of these extremes, and instead walk the straight and narrow between them.

I suppose, after all, that the final function of a preacher is to remind his flock that the straight and narrow path is not an easy one to walk. Performance work has never been easy. And so, I’m happy to tell you that in the coming pages you will find some of the best advice there is to be had on the subject - resources, guidance, examples, and a framework of values. And, after reading this guide, I hope you will want to work with us for what’s right for your customer - not only the most reliable and secure software that can be made, but also the most pleasant to use and reuse.

----
[1] Hoare, Tony. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." Quoted in Donald E. Knuth, Literate Programming (Stanford, California: Center for the Study of Language and Information, 1992), 276.

Comments

• Anonymous
  April 28, 2004
  Excellent! Do you happen to know if it is available in Word or Pdf format? I think it's a great read, but i don't like reading from my monitor. Thanks, Jonne

• Anonymous
  April 28, 2004
  I think PDF is coming very soon -- so you can take it to your local print shop and print it all in one go. Keep your eye on the link... maybe today even.

• Anonymous
  April 29, 2004
  Microsoft's

• Anonymous
  May 02, 2004
  Just from reading one chapter -- 13, the Code Review section -- I noticed a tremendous amount of typos, several which completely distorted the advice. I'd hold off getting a printed copy until a thorough editorial scrubbing is applied. Maybe 13 truly is an unlucky number :)
  
  But, I must say, so far, I like the advice :) Thanks to everyone involved.

• Anonymous
  May 02, 2004
  sigh I read those chapters for mistakes many many times but it's so easy to miss some.
  
  If you can be specific I can see that they get corrected especially if they are serious.

• Anonymous
  May 04, 2004
  The guide looks great, but is there any hope of that PDF being made available in the near future? Or won't the guide be released as PDF after all? Or is it just that I didn't look well enough, and the PDF is available already?
  

• Anonymous
  May 04, 2004
  I'm sorry about the delay, PDF is definately coming, many people want it, hang in there I will for sure advise as soon as I see it. I'm afraid I don't know what the cause of the delay but I know the Patterns and Practices team is very keen on getting that PDF out there.

• Anonymous
  May 05, 2004
  PDF now available... see seperate entry

• Anonymous
  April 28, 2006
  The comment has been removed

• Anonymous
  June 28, 2007
  For a compiler, the common things are code size vs. speed . The conventional wisdom is to optimize for

• Anonymous
  August 09, 2007
  The comment has been removed