CLR comprehensive and thorough parsing: Early and often rating performance, part 1th

As the performance architect for the Microsoft®.net Framework common language Runtime team, it is my job to help you get the most out of the run-time writing of high-performance applications. This is no mystery in. NET or in other languages-you just need to consider the performance issues of your application at the beginning of your design. There are many applications that do not consider performance issues at all when they are written. This is usually irrelevant because most programs have relatively little computational capacity, and the program is much faster to compute than the humans interacting with them. Unfortunately, when you really need a program with high performance, we lack the knowledge, skills, and tools to do it well.

Here I'll discuss what you need to know to write high-performance applications. I'll focus on programs written for. NET, but the concepts across languages are generic. Because. NET is more abstract to the underlying machine than the typical C + + compiler, and because. NET provides many powerful but costly features, including reflection, custom attributes, regular expressions, and so on, it is easy to inadvertently add costly operations to a performance-demanding code path. To help you avoid this overhead, I'll explain how to quantify the overhead of various. NET features to give you an idea of when these features should be used.

Make a plan

As I mentioned, most programs do not fully consider performance issues when they are written, but it is really necessary to develop a performance plan for each project. You must take into account the various user scenarios and clearly articulate what performance is excellent, good, or bad. Then, depending on the amount of data, the complexity of the algorithm, and previous experience in building similar applications, it is possible to easily meet the various performance goals defined. For many GUI applications, performance goals are moderate and can easily achieve at least a good level of performance without special design. In this case, your performance plan is complete.

If you don't know if you can easily meet your performance goals, you need to start planning to list all the possible bottlenecks. Typical problem areas include startup time, bulk data manipulation, and graphic animation.

Configuration file Data Processing sample

For example, this can be explained more specifically. I am currently designing the. NET infrastructure for processing profile data. I need to represent a list of operating system-generated events (such as page faults, disk I/O, context switches, and so on) in a meaningful way. The data files involved are usually larger, the smaller profiles are about 10MB, and the file size exceeds 1GB is not uncommon.

When I worked out the performance plan, I found that if I only counted the part of the dataset that needed to be redrawn on the screen, the data would not be a problem, in other words, the screen "slacking" was not a big problem. Unfortunately, it takes some extra work to make GUI objects such as tree controls, list controls, and text boxes "lazy". This is why most text editors can handle very large files (such as 100MB), and their performance is difficult to accept. If performance is not considered when designing the GUI, the result is almost certainly unsatisfactory.

However, deferred display is not helpful for operations that need to use all the data in a file (for example, when calculating summaries). Given the size of the dataset, the data dispatch and processing method is the "hot" code path that must be designed with the heart. Other parts of the program may not have strict performance requirements and therefore do not require special attention.

This is a very representative case. Even in scenarios where high performance is required, 95% of the application does not require any performance plan, but you need to seriously consider the last 5% of the performance plan. And, according to my experience, it's generally easy to determine 5% of the program's performance needs to be carefully considered.