MSDN Magazine - April 2008 - (Page 17)

Measure Early and Often for Performance, Part 1 VancE MOrrisOn A s a Performance Architect on the Microsoft® .NET Framework Common Language Runtime team, it is my job to help people best utilize the runtime to write high-performance applications. The truth of the matter is that there is no mystery to this, .NET or otherwise—you just have to design applications for performance from the start. Too many applications are written with almost no thought given to performance at all. Often that’s not a problem because most programs do relatively little computation, and they are much faster than the humans with which they interact. Unfortunately, when the need for high performance does present itself, we simply don’t have the knowledge, skills, and tools to do a good job. Here I’ll discuss what you need to write high-performance applications. While the concepts are universal, I’ll focus here on programs written for .NET. Because .NET abstracts the underlying machine more than a typical C++ compiler, and because .NET provides powerful but expensive features including reflection, custom attributes, regular expressions, and so forth, it is much easier to unwittingly inject expensive operations into a performancecritical code path. To help you avoid that expense, I’ll show how to quantify the expense of various .NET features so you know when it’s appropriate to use them. Have a Plan As I mentioned, most programs are written without much thought given to performance, but every project should have a performance plan. You must consider various user scenarios and articulate what excellent, good, and bad performance actually mean. Then, based on data volume, algorithmic complexity, and any previous experience building similar applications, you must decide if you can easily meet whatever performance goals you’ve defined. For many GUI applications, the performance goals are modest, so it’s easy to achieve at least good performance without any special design. If this is the case, your performance plan is done. If you don’t know if you can easily meet your performance goals, you’ll need to begin writing a plan by listing the areas likely to be bottlenecks. Typical problem areas include startup time, bulk data operations, and graphics animations. present a list of events (page faults, disk I/O, context switches, and so on) generated by the OS in a meaningful way. The data files involved tend to be large; small profiles are in the neighborhood of 10MB and file sizes well over 1GB are not unusual. While working on forming my performance plan, I concluded that the display of the data would not be problematEven in high-performance ic if I computed only the scenarios, 95 percent of the parts of the dataset that application does not need were needed to paint the display; in other words, if any performance planning, display was “lazy.” Unfortubut you need to carefully nately, it takes extra work to identify the last 5 percent make GUI objects like tree that does. controls, list controls, and textboxes lazy. This is why most text editors have unacceptable performance when file sizes get too large (say, for instance, 100MB). If I had designed the GUI without thinking about performance, the result would have almost certainly been unacceptable. Laziness, however, does not help for operations that need to use all the data in the file (when computing summaries, for example). Given the dataset size, the data dispatch and processing methods are “hot” code paths that must be designed carefully. Most of the rest of the program is unlikely to be performance-critical and needs no special attention. This experience is typical. Even in high-performance scenarios, 95 percent of the application does not need any performance planning, but you need to carefully identify the last 5 percent that does. Also, as in my case, it is usually pretty easy to determine which parts of the program are likely to be that 5 percent that matters. Measure Early and Measure Often Profile Data Processing Example An example will make this more concrete. I’m currently designing the .NET infrastructure for processing profile data. I need to The next step in high-performance design is to measure—before writing a line of code, you need to know whether your performance goals are even possible, and if so, what constraints they place on the design. In my case, I need to know the costs of basic operations being considered in my design, such as raw file I/O and database access. To proceed, I need some numbers. This is the most critical time in the design of the project. Sadly, most performance is lost very early in the development process. By the time you have chosen the data structures for the april2008 17

Table of Contents Feed for the Digital Edition of MSDN Magazine - April 2008

MSDN Magazine - April 2008 Contents Toolbox CLR Inside Out Basic Instincts Cutting Edge Foundations Test Run Service Station Windows with C++ Going Places { End Bracket }

MSDN Magazine - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.