Fact 2: If You’re Not Measuring, You’re Guessing
Profiles and measurements don’t lie. Profiles show you whether the CPU is fully loaded or if you’re
blocked on disk I/O. Profiles tell you what kind and how much memory you are allocating and whether
your CPU is spending a lot of time in garbage collection (GC).
You should set performance goals for key customer experiences or scenarios in your app and write tests
to measure performance. Investigate failing tests by applying the scientific method: use profiles to
guide you, hypothesize what the issue might be, and create an experiment or code change that you can
test to confirm the hypothesis or reject it. If you establish baseline performance measurements over
time with regular testing, you can isolate changes that cause regressions in performance. Approaching
performance work in a rigorous way avoids wasting time with code updates you don’t need.
Fact 3: Good Tools Make All the Difference
Good tools let you drill quickly into the biggest performance issues (CPU, memory, or disk) and help you
locate the code that causes those bottlenecks. Microsoft ships a variety of performance tools such as
Visual Studio Profiler, Windows Phone Analysis Tool, and PerfView.
Perfview is free and amazingly powerful for focusing on deeper issues (disk I/O, GC events, memory)
such as the issues demonstrated in the examples later. You can capture performance-related Event
Tracing for Windows (ETW) events and quickly see per application, per process, per stack, and per
thread information. PerfView shows you how much and what kind of memory your app allocates as well
as how much which functions or call stacks contribute to the memory allocations. For details, see the
very rich help, demos, and linked videos that download with the tool (such as these on channel 9).
Fact 4: It’s All about Allocations
You might think that building a responsive .NET Framework application is all about algorithms such as
using quick sort instead of bubble sort, but that's not the case. The biggest factor in building a
responsive app is allocating memory, especially when your app is very large or processes large amounts
of data.
Almost all of the work to build responsive IDE experiences with the new compiler APIs involved avoiding
allocations and managing caching strategies. PerfView traces show that the performance of the new C#
and Visual Basic compilers is rarely directly related to being CPU bound. The compilers can be I/O bound
when reading hundreds of thousands or millions of lines of code, reading metadata, or emitting
generated code. The UI thread delays are nearly all due to garbage collector. The .NET Framework GC is
highly tuned for performance and does much of its work concurrently while application code executes.
However, a single allocation can trigger an expensive collection and stop all threads (see generation 2
collections).
Common Allocations and Examples
The examples in this section have hidden allocations that appear small. However, if a large application
executes the example expressions enough times, these expressions can causes hundreds of megabytes,
评论0
最新资源