Performance By Design

Rico MarianiArchitectMicrosoft Corporation

Introduction

Part 1 – Teaching Performance Culture Part 2 – General Topics about Managed

Code

Rule #1

Measure Just thinking about what to measure will help

you do a good job Performance will happen

If you don’t measure you can be sure it will be slow, big, or whatever else you don’t want

If you haven’t measured, your job’s not finished

Rule #2

Do your homework Good engineering requires you to understand

your raw materials What are the key properties of your

Framework? Your processor? Your target system?

No more rules

Very few absolutes in the performance biz Performance work is plagued with powerful

secondary and tertiary effects that often dwarf what we think are the primary effects

Whenever considering advice you must remember Rule #1

Don’t let nifty sounding quotes keep you from great performance

Performance Culture

Budget an exercise to assess the value of a new feature

and the cost you’d be willing to pay Plan

validate your design against the budget, this is a risk assessment

Verify measure the final results, discard failures

without remorse or penalty, don’t make us live with them

Budget

Begin by thinking about how the customer thinks about performance Responsiveness Capacity Throughput Cost of Entry

Identify the resource the customer views as critical to this system

Choose the level of performance we want to deliver (do we need an “A+” or is a “D” good enough)

Convert this into what resource usage needs to be to succeed

Don’t think about the code, think about the customer

Plan

You can’t plan without a budget, so get one Use best practices to select candidate algorithms Understand their costs in terms of the critical

resource Identify your dependencies and understand their

costs Compare these projected costs against the budgets If you are close to budget you will need much greater

detail in your plans Identify verification steps and places to abort if it

goes badly Proceed when you are comfortable with the risk

Verify

The budget and the plan drive verification steps

Performance that cannot be verified does not exist

Don’t be afraid to cancel features that are not meeting their budgets – we expect to lose some bets

Don’t inflict bad performance on the world

What Goes Wrong (I)

Programs take dependencies that they fundamentally cannot afford E.g. Hash and comparison functions that call

string splitting functions Solution

Understand the costs of your dependencies in terms of your critical resource

Use dependencies in the context they were intended

What Goes Wrong (II)

Programs use an algorithm that is fundamentally unsuitable E.g. mostly sorted data passed to a quicksort

Solution Model your real algorithm with real data before

you assume its ok

What Goes Wrong (III)

Programs do a lot of work that doesn’t constitute “forward progress” E.g. converting from one format to another in

multiple stages each of which re-copies the data

Solution Score your algorithms relative to the minimum

work required to get the job done This is the number one reason code is slower

than it could be

What Goes Wrong (IV)

Programs are designed to do more than they need to do E.g. arbitrary extensibility even to the point

where it is too complicated to be useful Solution

Focus only on your customers needs Usable first, then re-usable

Selected Topics (I) : Object Lifetime

Good lifetime looks like single digit time in the collector

Bad lifetime looks like Mid-life Crisis in the Datacenter

Selected Topics (II) : JIT, Ngen, GAC

Many consequences, no perfect answer Jitting implies private pages

Why is that bad? Why can it be good?

Ngen is designed to combat these effects But it’s a mixed blessing too Shareable code has its costs/benefits

GAC increases the usefulness, also at cost

Selected Topics (III) : Measurement

Choose the right tool for the right problem Identify sources of consumption (perfmon) Consider

CPU profilers (like the one in Visual Studio Team System) Memory profilers, like CLRProfiler Resource trackers like filemon, regmon

ETW gives you the best of everything, especially on Vista – but the tooling is still immature

Selected Topics (IV): Collection Classes

The most glaring performance problems (e.g. enumeration of ArrayList were addressed by the Generic collections, chance for a redo)

Beware of using Collections as your “flagship storage” – they are not the most frugal

Selected Topics (V): Exceptions

Managed code pays less for the presence of exceptions, but pays more for the throws rich state capture, complex state examination

Use of exceptions for anything unexceptional can easily torpedo your performance

Exceptions access “cold” memory

Final words

Understand your goals Understand the costs of what you use Be ruthless about measuring so that you’ve done the full

job Keep reading and experimenting so you can learn aspects

of the system that are most relevant to you Share your wisdom with your friends Insist on performance culture in your group Don’t forget Rule #1 and Rule #2 !!!

References

Rico Mariani’s Performance Tidbits http://blogs.msdn.com/ricom

Patterns and Practices Performance References http://msdn.microsoft.com/en-us/library/aa338212.aspx

“Maoni’s Weblog” http://blogs.msdn.com/maoni/

“If broken it is, fix it you should” http://blogs.msdn.com/tess/

© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market

conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.