Foreword

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Improving .NET Application Performance and Scalability

J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman
Microsoft Corporation

May 2004

Related Links

Home Page for Improving .NET Application Performance and Scalability

Send feedback to Scale@microsoft.com

patterns & practices Library

By Rico Mariani

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.

Rico Mariani
Performance Architect
Microsoft Corporation
March, 2004

Rico Mariani is a Performance Architect in the Developer Division at Microsoft. Rico began his career at Microsoft in 1988, working on language products beginning with Microsoft® *C version 6.0, and contributed there until the release of the Microsoft Visual C++*® version 5.0 development system. In 1995, Rico became development manager for what was to become the "Sidewalk" project, which started his 7 years of platform work on various MSN technologies. In the summer of 2002, Rico returned to the Developer Division to take his present position as Performance Architect on the CLR team. Rico's interests include compilers and language theory, databases, 3-D art, and good fiction.

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.

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.