Lập trình Wrox Professional Xcode 3 cho Mac OS part 67 ppt

Performance analysis best practices Analyzing code - level performance with Shark Analyzing everything else with Instruments Solving common performance problems Whether it ’ s a rollerco

Trang 1

Performance Analysis

WHAT'S IN THIS CHAPTER?

Performance analysis best practices Analyzing code - level performance with Shark Analyzing everything else with Instruments Solving common performance problems Whether it ’ s a rollercoaster ride or a visit to the dentist, a lot of times you just want things

to go faster — and the applications you build with Xcode are no exception Speeding up an application entails fi nding and eliminating ineffi cient code, making better use of the computer ’ s resources, or just thinking differently Neither Xcode nor I can help you with the last one

Sometimes the most dramatic improvements in a program are those that come from completely rethinking the problem There are, sadly, no developer tools to simulate your creativity

The more mundane approaches are to reduce the amount of waste in your application and to harness more of the computer system ’ s power To do that you fi rst need to know where your application is spending its time and learn what resources it ’ s using In simple terms, to make your application run faster you fi rst need to know what ’ s slowing it down This is a process known as performance analysis, and for that, Xcode offers a number of very powerful tools

Recent versions of Xcode consolidate a wide variety of performance analysis tools that,

in prior versions, were individual applications In Xcode 3.2, the former rag - tag band of developer gizmos has been gathered together under a single umbrella called Instruments I do not exaggerate when I say that Instruments is the single greatest advancement in Macintosh debugging ever, but it hasn ’ t replaced every tool You ’ ll still make regular use of the debugger (Chapter 18) and you ’ ll also want to use Shark, a dedicated code - level analysis tool

This chapter discusses some of the principles of performance analysis, Shark, and Instruments The manual for Instruments is excellent — just search the Xcode documentation for “ Instruments ” — so this chapter won ’ t go into too much detail about every instrument and

➤

Download at getcoolebook.com

Trang 2

display option Instead, I show you how to use Instruments in an Xcode - centric workfl ow and walk

you through the solution to three very common performance problems

PERFORMANCE BASICS

The term performance means different things to different people This chapter concentrates on the

simplest and most direct kind of performance enhancement: getting your application to run faster

In general, this means getting your program to work more effi ciently, and therefore fi nish sooner

In the real world, this is too narrow of a defi nition, and performance solutions are sometimes

counterintuitive A graphics application that draws a placeholder image, and then starts a background

thread to calculate successively higher resolution versions of the same image, might actually end up

drawing that image two or three times Measured both by the raw computations expended and by

clock time, the application is doing much more work and is actually slower than if it had simply

drawn the fi nal image once From the user ’ s perspective, the perceived performance of the application

is better It appears to be more responsive and usable, and therefore provides a superior experience

These are the solutions that require you to think “ different, ” not just think “ faster ”

When considering the performance of your application, keep the following principles in mind:

Optimize your code only when it is actually experiencing performance problems

People are notoriously bad at estimating the performance of a complex system

Combining the fi rst two principles, you probably have no idea what or where your performance problems are

Set performance goals for your program and record benchmarks before starting any

performance enhancements Continue making, saving, and comparing benchmark results throughout your development

If It isn ’ t Broken

The fi rst principle is key; don ’ t try to optimize things that don ’ t need optimizing Write your

application in a straightforward, well structured, easily maintained, and robust manner This

usually means writing your application using the simplest solution, employing high - level routines,

objects, and abstractions Given the choice of using a neatly encapsulated class and a collection of

C functions that do the same thing, use the class

Now run your application and test it If, and only if , its performance is unacceptable should you

even consider trying to speed it up Your current solution might be taking a simple 4 - byte integer,

turning it into a string object, stuffi ng that into a collection, serializing that collection into a data

stream, and then pushing the whole mess into a pipe — whereupon the entire process is promptly

reversed You might recoil in horror at the absurd ineffi ciency used to pass a single integer value,

but computers today are mind - numbingly fast All that work, over the lifetime of your application,

might ultimately consume less CPU time than it takes you to blink

➤

Trang 3

In addition, optimization makes more work for you now and in the future Optimized code is notoriously more fragile and diffi cult to maintain This means that future revisions to your project will take longer and you run a higher risk of introducing bugs So remember, don ’ t fi x what ain ’ t broke Every optimization incurs a cost, both today and in the future

Embrace Your Own Ignorance

Modern computer languages, libraries, and hardware are both complex and subtle It is very diffi cult to guess, with any accuracy, how much time a given piece of code will take to execute

Gone are the days where you could look at some machine code, count the instructions, and then tell how long it would take the program to run Sure, sometimes it ’ s easy Sorting a hundred million of anything is going to take some time Those kinds of hot spots are the exception, not the rule Most of the time the performance bottlenecks in your application will occur in completely unexpected places

Another common fallacy is to assume you can write something that ’ s faster than the system Always start by using the system tools, collections, and math classes that you have available to you Only if those prove to be a burden should you consider abandoning them You might think you can write

a better sorting routine, but you probably can ’ t Many of the algorithms provided by Apple and the open source software community have been fi nely tuned and tweaked by experienced engineers who are a lot smarter than you or I

Combining the fi rst two principles, you can distill this simple rule:

Don ’ t try to guess where your performance problems are

If you have a performance problem, let the performance analysis tools fi nd them for you

Improve Performance Systematically

The last bit of advice is to have a goal and measure your progress Know what the performance goals of your application should be before you even begin development Your goals can be

completely informal You may simply want your application to feel responsive If it does, then

you ’ re done Most of the time you will not need to do any performance analysis or optimization

at all

If your application ’ s performance seems sub - optimal, begin by measuring its performance before you try to fi x anything If you accept the earlier principles, this is a prerequisite: you must measure the performance of your application before you can begin to know where its problems are Even if you already know, you should still benchmark your application fi rst You can ’ t tell how much (or if any) progress has been made if you don ’ t know where you started from

Continue this process throughout the lifetime of your application Applications, like people, tend to get heavier and slower over time Keep the benchmarks you took when you fi rst began, and again later after optimization Occasionally compare them against the performance of your application as you continue development It ’ s just like leaving a set of scales in the bathroom

➤

Performance Basics ❘ 513

Trang 4

PREPARING FOR ANALYSIS

Most of the performance analysis tools, especially ones that analyze the code of your application,

need debug symbol information They also need to analyze the code you plan to release, not the

code you are debugging If you ’ ve been building and testing your application using the debugger

(covered in Chapter 18), you probably already have a build confi guration for debugging The

debugger needs debugging symbols on and all optimization turned off Your released application

should be fully optimized and free of any debugger data Performance analysis sits right between

these two points It needs debugging symbols, but it should be fully optimized Without the

debugging symbols, it can ’ t do its job, and there ’ s no point in profi ling or trying to improve

unoptimized code

If you ’ re using the modern DWARF with dSYM fi le debug information format, set up your Release

build confi guration as follows:

The DWARF with dSYM fi le format writes the debugging information to a separate dSYM fi le that ’ s

not part of your fi nal product The end result is a fi nished application that ’ s (mostly) stripped of

any debugging information, along with a companion dSYM fi le that provides the debugger and

performance analysis tools with all of the information they need This is the build confi guration

you ’ ll fi nd if you created your project using any of the modern Xcode project templates

If you ’ ve inherited an older project, created one with an earlier version of Xcode, or can ’ t use the

DWARF with dSYM fi le format for some reason, you ’ re going to need a special build confi guration

for performance analysis Create a new build confi guration specifi cally for profi ling by doing the

following:

1. In the Confi gurations pane of the project ’ s Info window, duplicate your Release build

confi guration, the confi guration used to produce your fi nal application Name the new confi guration “ Performance ”

2. In the Performance confi guration for all of your targets and/or the project, turn on Generate

Debug Symbols Turn off Strip Debug Symbols During Copy

Switch to this build confi guration whenever you need to do performance analysis and

enhancements If you change the code generation settings in your Release confi guration, remember

to update your Performance confi guration to match

SHARK

Shark is a code performance analysis tool, and is the premier tool for optimizing your code ’ s

raw execution speed It works by periodically sampling the state of your application from which

it assembles an approximate overview of its performance Though Instruments has similar tools,

Shark is purpose - built for optimizing code and is my fi rst choice when that ’ s my singular focus

➤

Trang 5

Shark can be used on its own in a variety of modes, but you ’ re going to start it directly from within Xcode First, build your target using your performance build confi guration From the menu choose Run ➪ Launch Using Performance Tool ➪ Shark

Remember that the items in the Run ➪ Launch Using Performance Tool menu do

not build your project fi rst Get into the habit of performing a build (Command+B)

before starting any performance tool, or you ’ ll be analyzing old code.

When Xcode starts Shark, it tells Shark which executable to analyze and describes its environment — saving you a lot of confi guration work in Shark The initial window, shown at the top of Figure 19 - 1, selects the type of analysis that Shark will perform The useful choices are:

Time Proﬁ le Optimizing the raw performance of your code Time Proﬁ le (All Thread States) Speeding up your application by looking for delays caused

by either your code or system routines your code calls Time Profi le (WTF) Same as Time Profi le, but analyzes a fi xed time period

ending when Shark is stopped

Shark can perform many different kinds of analyses, but only a few make sense when you ’ re launching a single process from Xcode Many of Shark ’ s other modes also overlap those in Instruments, and for those cases you ’ ll probably be better served by the latter

All the choices in the analysis menu are named, editable confi gurations supplied

by Shark You can change these confi gurations (Confi g ➪ Edit) or add your own (Confi g ➪ New), much the way you redefi ne batch fi nd options in the Project Find window.

The Time Profi le measures the performance of your application ’ s code The All Thread State variant includes time spent waiting for system routines Think of it as optimizing process time versus optimizing elapsed time

Normally, Shark captures a fi xed number of samples or for a fi xed time period — parameters you can change by editing the confi guration — stops, and then performs its analysis The Windowed Time Facility (WTF) mode captures samples indefi nitely into a circular buffer When stopped, it analyzes the latest set of samples In other words, regular analysis starts at some point and analyzes

a fi xed time period beyond that point WTF analysis ends at some point and analyzes the time period

up to that point

Shark ❘ 515

Trang 6

To profi le a Java application, choose one of the Java - specifi c analysis modes in

argument in the Arguments pane of the executable ’ s Get Info window You might want to create a custom executable just for Shark profi ling, or just disable this argument when you are done

Java and Xcode have an on - again, off - again romance — Apple alternately breaks Java support in Shark and then fi xes it again Some combinations of the Java run time and Xcode analysis tools don ’ t work well together, if at all.

Consult the Java release notes or inquire on the Xcode - users discussion list if you are having problems.

To start a Shark analysis of your application simply click the Start button, or press Shark ’ s hot

key (Option+Esc), and a launch process confi guration dialog box appears, as shown in Figure 19 - 1

The dialog has been preconfi gured by Xcode, so you shouldn ’ t have much to do Before beginning

your analysis, you can choose to modify the command - line parameters or environment variables

passed to your application This example passes an argument of “ 150000 ” to the program for

testing The menu button to the right of the Arguments fi eld keeps a history of recently used

argument lists

FIGURE 19-1

Trang 7

You can also attach Shark to a currently running application If you ’ ve already started your application from Xcode, launch Shark and choose your running process from the menu at the right of Shark ’ s control window Click the Start button, or switch back to your application and use Shark ’ s hot key (Option+Esc) to start sampling at a strategic point

Proﬁ le View

Your program runs while Shark is analyzing it Shark stops its analysis after your program has terminated, when you stop it yourself using the Stop button, by pressing Shark ’ s hot key (Option+Esc), or when Shark ’ s analysis buffer fi lls up — typically 30 seconds ’ worth Shark then presents its profi le of your application ’ s performance, as shown in Figure 19 - 2

FIGURE 19-2

Figure 19 - 2 shows the Tree (Top - Down) view of your application ’ s performance in the lower pane

The columns Self and Total show how much time your program spent in each function of your application The Self column records the amount of time it spent in the code of that particular function The Total column calculates the amount of time spent in that function and any functions called by that function The organization of the tree view should be obvious, because it parallels the calling structure of your application Every function listed expands to show the functions that it called and how much time was spent in each

Shark ❘ 517

Trang 8

The compiler ’ s optimization can confuse Shark as well as the debugger Take the following code as an example:

main() { calc();

} int calc( ) {

return (subcalc());

} int subcalc( ) {

return (x);

}

rather than a function call It might pop the existing stack frame before calling

subcalc , or jump to subcalc() and let it use the stack frame for calc() Either

way, it has avoided the overhead incurred by creating and destroying a stack

The Heavy (Bottom - Up) view is shown in the upper pane of Figure 19 - 2 You can choose to see the

Tree, Heavy, or both views using the View menu in the lower - right corner of the window

The Heavy view inverts the tree Each item is now the amount of time spent executing the code

within each function This does not include any time spent in functions that this function might

have called When you expand a function group, you see the list of functions that called that

function The times for each break down the amount of time spent in that function while being

called from each of the calling functions listed

The Tree view gives you a bird ’ s - eye view of where your application is spending its time, starting

with the fi rst function called (where it spends all of its time), and subdividing that by the subroutines

it calls, the subroutines called by those subroutines, and so on The Heavy view determines which

functions use up the most of your program ’ s CPU time This view works backward to determine

what functions caused those heavily used functions to be called, and how often

You can use this information in a variety of ways The typical approach is to use the Heavy view

to see which functions use the most time Those are prime candidates for optimization If you can

make those functions run faster, anything that calls them will run faster too Both the Heavy and

Tree views are also useful for fi nding logical optimizations This usually entails reengineering the

callers of heavy functions so that they get called less often or not at all Making a function faster

helps, but not calling the function in the fi rst place is even quicker

At the bottom of the window are the Process and Thread selections These two menus enable you

to restrict the analysis to a single process or thread within that process Set one of these menus to

something other than All, and only samples belonging to that thread or process are considered

Because Xcode launched Shark for this particular application, there is only one process If the

Trang 9

application you launched runs in multiple threads, select the thread you want to analyze The status line above these two controls displays the number of samples being considered

STATISTICAL SAMPLING

At this point, you might be wondering how Shark obtained all of this information

Shark is one of a class of tools known as samplers Shark interrupts your application

about a thousand times every second and takes a (very) quick “ snapshot ” of what

it ’ s doing After these samples have been gathered, Shark combines all of the samples to produce a statistical picture of where your program spends its time

Think of trying to analyze the habits of a fi refl y You set up a high - speed camera

in the dark and fi lm the fi refl y as it fl ies around After you ’ ve got several thousand frames, you could compose all of those frames into a single picture like a single long exposure Points in the picture that are very bright are where the fi refl y spent most of its time, dimmer spots indicate places where it visited briefl y, and the black portions are where it (probably) never went at all This is exactly what the Heavy view shows — the accumulated totals of every snapshot where Shark found your application in a particular function at that moment

The word “ statistical ” is important Shark does not trace your program nor does

it rigorously determine exactly when each subroutine was called and how long it took to run It relies entirely on taking thousands of (essentially) random samples

Functions that execute very little of the time may not even appear Shark can only

be trusted when it has many samples of a function — which is perfect, because you ’ re usually only interested in the functions that take up a signifi cant amount of time The ones that don ’ t aren ’ t worth optimizing

Code View

The profi le view is useful for identifying the functions that are candidates for optimization, but what in those functions needs optimizing? Double - click any function name and Shark switches to a code view of that function as shown in Figure 19 - 3

FIGURE 19-3

Shark ❘ 519

Trang 10

The code view shows the amount of time your application spent in each line of your function, or,

to put it more precisely, it shows the percentage of time that it found your application at that line

of source code when it captured a sample Source view requires that you compiled your application

with full debug information, and that information was not stripped from the executable If there

is no debug information available, you ’ ll see the machine code disassembly of the function instead

If you really want to get into the nitty - gritty details of your code, change the listing to show the

machine code, or both the machine and source code side by side, using the buttons in the upper

-right corner

Shark highlights the “ hot spots ” in your code by coloring heavily used statements in various shades

of yellow This shading continues into the scroll bar area so you can quickly scroll to hot spots

above or below the visible listing Even though the window will scroll through the entire source fi le

that contains the function you are examining, only the statistics and samples for the function you

selected are analyzed If you want to scrutinize samples in a different function, return to the Profi le

tab and double - click that function

The truly amazing power of Shark really becomes evident in the code view Shark analyzes the

execution fl ow of your code and makes suggestions for improving it These suggestions appear as

advice buttons — small square buttons with exclamation points — throughout the interface One is

shown in Figure 19 - 4 Click an advice button and Shark pops up a bubble explaining what it found

and what you might do to improve the performance of your code

FIGURE 19-4

The advice feature is quite sophisticated; many of its suggestions require the analysis of code fl ow,

instruction pipelining, and caching features of various processors Shark can recognize when

you are dividing where you might be better off with a bit shift instead, or where loops should be

unrolled, aligned, and so on It ’ s like having a CPU performance expert in a box

Every time you link to a code view from the summary window it creates another tab at the top

of Shark ’ s analysis window Close the tab or navigate back to the profi le pane Jumping from one

Định dạng
Số trang	15
Dung lượng	4,71 MB