Who Am I and What Am I Doing Writing a Blog?
My name is Mark Friedman and I have been working here at Microsoft as an Architect in the Developer Division Performance Engineering team since October 2006. Although I am a newbie here, I am an industry veteran with an extensive background in software product development, particularly in developing monitoring tools for finding and resolving performance problems. These experiences include designing and developing several major products that brought me a modest measure of fame and fortune.
Although I consider myself primarily a software developer, over the years, I have also written extensively on performance-oriented topics, including two books on the subject of Windows performance, most recently, the Performance Guide that is packaged with the Windows Server 2003 Resource Kit. You can find bunches of articles I have written over the years for the Computer Measurement Group annual conference and its MeasureIT online publication or at the web site of my previous company.
If you bother to track down some of the links above, you will notice that I have not been writing much for public consumption lately. This prolonged period of what might look like writer’s block is due to my starting on this job to orient myself around what is to me a new technical challenge, namely developing a deep understanding of application performance on the Windows platform. The Developer Division produces a number of major applications, including Visual Studio, the Visual Studio Team System, the Team Foundation Server, the Expression suite of designer tools for web development, the C++, C#, and Visual Basic compilers, the Common Language Runtime (CLR), and the .NET Framework. This is a very diverse set of software products, to say the least. When you factor the myriad ways customers can wield these developer tools and technologies to build their applications, the word “diverse” doesn’t seem adequate to the task. Something along the lines of Universal Turing Machine seems more apt.
Software Performance Engineering (SPE), which is my team’s charter, is the discipline associated with building responsive and highly scalable applications. The problem we face is how to apply the principles and best practices associated with SPE to the engineering practices Microsoft uses to build the complex software we sell to customers. Furthermore, we want to incorporate successful practices and procedures into the developer tools we sell to customers. This would help them develop Windows-based applications that meet stringent performance and scalability requirements.
One particularly sobering aspect of this challenge is that there is no fully realized blueprint anywhere in the software industry for successfully integrating the performance engineering discipline into the application development life cycle. This has been a problem nagging advocates of the SPE approach from its very inception. Today, for example, there are a number of excellent books available on the subject suitable for general practitioners, including Connie Smith and Lloyd Williams’ Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software. Smith and Williams’ book is probably the most thorough practical guide available for the practitioner. I also happen to be particularly partial to Daniel Menasce, et. al., Performance by Design: Computer Capacity Planning By Example, but that approach is more informed by analytic modeling, rather than the software development lifecycle. But neither book is specific to the Microsoft platform in general and the .NET Framework in particular.
The performance engineering guide that comes closest to addressing the specific needs of the .NET developer is Improving .NET Application Performance and Scalability. This valuable book provides an enormous amount of practical guidance to the .NET developer. I don’t like to think about the Herculean effort it took to produce this extensive developer’s guide, mainly because it will probably be my responsibility to produce the next edition of it. It is almost encyclopedic in scope. Even so, in my view, the advice contained in the book could be improved in at least one key area, which would be the adoption of the empirical, measurement-oriented approach I advocated in my two Windows performance books.
The number of public APIs in the .NET Framework is enormous, not to mention its extensibility by third party component developers and your in-house programmers. These object-oriented components can then be assembled into an executable program in any imaginable combination. When you factor in the need to consider all possible (or likely) permutations of .NET classes and their methods, my belief is that no static set of developer guidelines can ever be adequate to the task. This, by the way, is not meant to diminish my enthusiasm for an initiative my colleague Rico Mariani calls performance signatures, which he has discussed extensively on his blog, which relies on static analysis. I am sure Rico is correct in the value of some form of static analysis. But, in addition to a static analysis, we also have to measure the application’s performance empirically to see if its execution is taking too long and then determine why. In my mind, the pattern developed in the relational database world around having both a static definition of the execution Plan chosen by the Optimizer and a dynamic Explain function is probably worth copying.
If you are a .NET developer interested in building a highly scalable application, you are currently pretty much on your own in trying to figure out how to get started. Fortunately, basic performance considerations for .NET developers are not that different than for any other computing platform. But the .NET Framework is so wide and deep, getting going is a daunting prospect. Picking up a copy of Improving .NET Application Performance and Scalability, which runs to slightly more than 1000 pages, is also quite intimidating.
This is also a problem I face in starting to write about this problem space. The subject is so broad and so deep, it is difficult to know quite where the best place to start is. Under these circumstances, blogging about the area more informally than I might otherwise attempt in writing about this subject seems like a reasonable way to get started. I also work collaboratively with a remarkably talented group of individuals here in the Developer Division who share my interest and passion for application performance. They are accomplished authors on their own, too. I will attempt to structure this blog as a team effort so you have a chance to read their contributions to our understanding of this area as well.
So, if you don’t mind reading a work in progress, please stay tuned. If following me down a blind alley from time to time is a prospect that will dishearten you, I suggest you wait for the polished book version. But I warn, you that is probably at least several years in the future. What I intend to blog about over the next few months is our first tentative steps to formulate an empirical approach to engineering .NET application scalability, informed both by my background in computer performance and access to the internals of Windows, the CLR, and the .NET Framework. Someday, this might form the makings of a decent book on the subject, perhaps version 2 of Improving .NET Application Performance and Scalability. But, fair warning, much of what we will be writing about is preliminary, as we work out the most effective set of techniques.
Initially, I expect you will see me writing on an unholy mix of three topics that I am currently thinking about the most:
1. Parallel computing, including the multi-core hardware that we can expect and the challenge being issued to programmers to exploit it in the software we develop. I am not sure that I have anything terribly original to say about this topic, but I would at least like to acknowledge its scope and report on what tangible progress I see being made here in this important area.
2. The performance of the Collection classes, which is really a proxy for a wider larger discussion about what software architects and developers need in terms of run-time instrumentation to deal effectively with performance and scalability considerations with the .NET Framework. There are currently some 30 million lines of code in the Framework, so it meets almost anyone’s definition of a huge surface area that developers must understand and interact with in order to be successful. Collections of one sort or another are a good choice to help frame this discussion because they are key elements of almost every substantial application that is built using .NET. Moreover, the choice of which Collection class to use in your application is one of the key decisions developers have to make. Some form of performance intellisense (RicoM’s phrase) to help catch poor choices during application design and coding would undoubtedly be a cool feature in Visual Studio. But, realistically, there is no way to say whether the developer has selected the right Collection class until we understand both the size (or cardinality) of the collection and the way it is accessed.
3. Finally, I plan to write a few blog entries on the subject of performance and scalability testing. Performance testing is another area where the Microsoft Patterns and Practices group has published a healthy amount of guidance. Hopefully, I can contribute something in this space that is specific to the .NET application platform.
<:AtomicElement><:HighlightText>
Photo credit: The copyright-protected artwork used in the logo is provided courtesy of James Neff. It is used with the permission of the artist. It is entitled “1947 Mt. Rainier, Washington.” The picture commemorates the detailed, widely reported sighting of UFOs by Kenneth Arnold, a businessman and pilot, in 1947 near Mt. Rainier in Washington, which led to the first coining of the term “flying saucers” to describe the encounter. Reproductions of the artwork suitable for framing are available for sale at https://www.rense.com/prints.htm. By the way, Mr. Arnold never claimed he saw saucer-shaped UFOs, but that was the terminology that captured the imagination of the public. He claimed he saw wing-shaped vehicles flying at great speeds. What he did marvel at was the way these UFOs seemed to float and move like saucers being skipped across a lake or stream.