Well good morning everyone. Thank you for coming to the What's New with Instruments session. My name is Steve Lewallen, I'm the manager of performance tools here at Apple and today we're going to learn about all what's new in Instruments. So let's get started. So today we're going to learn about a new, improved user interface. We're also going to talk about significant recording techniques that I think will be very helpful for you all to know. And we're going to talk about advancements to existing Instruments. And finally we're going to discuss more about our significant new Instruments. So, let's talk about the UI.

Front and center in the user interface is the Jump bar. This shows you where you are and how you got there. It's possibly the most important UI control in the interface. You can use this to switch between Instruments and a particular trace document and you can use it to switch between detail views of a particular instrument. And then let's say you focused in on some important piece of data from one detail view, you want to get back to where you came from, just click anywhere on the Jump bar. For example, the previous segment, that'll take you right back.

So we've also improved how you can access the views and see the data in Instruments. So now you can collapse away just about anything you don't want to see. Collapse away the track view, collapse away the Instruments list and configuration panel on the left. Collapse away the extended detail view. And if that's not enough, you can go full screen which now has the mini bar. If you move your mouse to the top of the screen the mini bar appears, move it away it goes away. Same thing as the rest of the full screen Mac apps.

And we've also made so many improvements in the call tree, I think we can declare it is the coolest call tree in the universe, if that's possible. So to do that the first thing we did is give you more room for that symbol tree. I think that's the most important part of that interface. We did that by combining several columns together and affording more room for the symbol tree itself.

We also enabled the call tree to slide under the statistics view. So you always had the problem where when you had a node far to the right and you scrolled and scrolled you got it into view and then the statistics scroll off the screen, you couldn't see how much was attributed to that node. So now you can.

Another problem that people would have in using any outline view is that it's hard to understand what is a sibling of another node or what are the children of a node. So we added what we call sibling banding. So you select a node and you'll see this vertical band appear and then you can scroll up and down as much as you want and rest assured that anything to the right of that band is going to be a child node within the selected hierarchy. And of course, when you move your mouse over the nodes, you also get a highlighting sibling band as well.

We also added, as with Xcode 4, backtrace compression filtering. This is really handy. Basically, this allows you to use the slider you find at the bottom of the back trace, to collapse library boundaries down to just your own code. So you can see what called your code and then focus on your frames itself. Very handy.

And of course we have the source view, where we have performance data in line with the source. What we've done with the latest release is allow you to access this directly from other data views. So for example, in the picture before you, we're on the call tree view, if we double-click on this Create New Game API, that will move into the Jump bar and the source view will come in.

To go back to the call tree, just click one of the items in the Jump bar. Very simple. And of course, all the annotations are colored by severity. So you want to pay most attention, soonest, to those things colored the darkest. And we also have full disassembly view, both for Intel and ARM and we still include the performance annotations in those views. You can see this by function or you can see it per annotation. So if you want to see just the disassembly for the line of annotation, you can do that.

And we have timeline views. You can think of these as bookmarks for the trace document. You can add these manually yourself. So you see something important happen, you want to remember it later. You Option-click in the ruler and add your own flag. We also had Instrument, last year the Zombie's instrument which detects when over-released objects are messaged. We had that add its own timeline flag itself automatically.

And now in the latest iPhone OS 4.0 SDK, we show multistate app transitions in the ruler as well. So when your app goes from being running in the foreground to transitioning to the background running and then suspended in the background, etcetera, you can see flags for those and that will explain to you later when you look at this trace document, a week from then you know, why CPU activity dropped off, for example. Well it's because it became suspended in the background.

So now let's go and take a look at a demo of Instruments and we'll just sort of learn our way around Instruments and solve a couple of problems using a couple of very common instruments. So I'm going to go over to my computer here. Let me go to the demo machine. All right.

So a colleague of mine has been writing a reader app and I liked it so much I was using it, but I wanted it to remember the state that it had, the book I was reading and the place within the book and restore that the next time I launched the app. So I went ahead and did that and let's just see how that looks in the simulator. So here it is, it restored the state. If I go somewhere else, pick a different book here, scroll up to the title.

We'll quit that and I'll click it again and it restores its state back. So this is great. This is awesome. I'm so excited, I'm just ready to push this to the App Store right away. But I've only tested this on the simulator. What I really should do is test this on the device as well, because the performance on the device is going to be different than the performance on a desktop computer.

So let me quit the app and let's switch to the iPhone in WolfVision here. I'll switch the device, build and run and it's compiling, linking, installing the app and still there it is. And boy that's taking a long time. OK, there's my app. Well clearly the performance characteristics on start up was very different on the device than it was in the simulator. So, back to the demo machine please.

What I want to do is to use the Time Profiler, new in iPhone 4.0 SDK and to see why that's taking so long. So let me go to Instruments and by the way, don't get confused. There are two sets of tools here. One is the latest SDK tool set that shipped and one is the Xcode for our preview. We'll be using both in this session. So let me open the shipping version of Instruments here and I am going to time profile the reader app.

So I will go up to my iPhone section and double-click on Time Profiler and I will pick my little reader app and let's start it up. And when this, when the page displays on the phone, I'm going to stop this. So there we go. So let's see what's taking so long in this code. So the first thing I want to do is I want to focus in on my code. So what I like to do first is hide system libraries and maybe hide any missing symbols I have.

And then I will focus in on this text view controller viewDidLoad, that seems to be taking up an enormous amount of time. And I can see, I come to main and the view is loading. Oh, this is where I'm actually restoring that state and we come into viewDidLoad, let me double-click on that and move this over some, ah, so I'm taking the contents of the book and I'm setting it on the text view. Hmmm, well there's nothing really I can do about that.

I mean, I could, I could spend the time during today, tomorrow and the next day, re-architecting my app, but we don't' have time for that. So what I'd really like to do and what's common when you have an app that requires a lot of start up preparation, is it's a great thing to make it a background app. So let's go ahead and do that. I'm going to quit Instruments here.

The first thing I need to do is go to my Info.plist and I'm going to say that actually I do want this to run in the background and I'll save that. And then, in case I've switched to the background and for whatever reason the system had to terminate my app, I want to make sure that I capture the state that I currently have in there. What book I'm reading again and where I am in that book. So let me go to my delegate and just like I did earlier, where I had already added save application state and application will terminate, I want to do that when I'm doing it from the background.

So let me say self save application state and save and I'll build and run again and we can see how this works out. So let's go back to the device in WolfVision there and it's running and of course we haven't solved the initial start up cost, but let's see how backgrounding works for us.

OK, the app has started. So what I'm going to do now is click the Home button, it's gone to the background and make it come back. Excellent. So it comes back very quickly. That's a much better user experience. So we can go back to the demo machine again.

So now I'm ready to ship my app right? I mean, all I did was take an API used in one place and just used it somewhere else that I never really intended it to be used for and this is going to run all the time now in the background, but what could go wrong right. Well, if it's running in the background, I have a responsibility to make sure I control my memory overhead. I don't want to be leaking any memory for example. So I doubt there's any leaks, but let's check anyway.

So we'll just stay on the demo machine and another way that you can run Instruments against your app, is actually from Xcode itself. So I go up to run with performance tool, down to leaks. And this will start up the app, start up Instruments on the device, etcetera and we'll see if we have any leaks.

So the first thing I'm going to do is disable automatic leaks checking. Leaks is automatically set up to do this every ten seconds or so, but I want to make this go back and forth on the phone a little bit before we do that. So I'm going to just keep you eye on the Mac here, but I'm going to make that device, the app go to the background and bring it to foreground, maybe do that a couple of times.

OK. And now let's check for leaks. It's analyzing the process here and that just takes a little bit of time as it goes over, oh I do have a leak. Who would have thought? OK, well what I want to do now is stop the trace. I want to investigate these leaks. So what I can do is focus in on one of them. When you see one of these circles with an arrow in them, in the table views and in ally views, those are Focus buttons.

So if I click on one of those, I'm going to see that the address I focused on is now added to the Jump bar. And so for example, if I wanted to go back to the view I was at, I just go up to the Jump bar once, to this leaks blocks element, I click it and I'm back. Let's go and investigate that leak. So let's focus in again and let me open the extended detail view. And now let me actually use a stack compression to focus in on just my own code.

Great. So now I can see really just my own code. If we zoom in here we can see, oh the leak is actually coming from the saveapplicationstate [assumed spelling] call. Hum, well I better take a look at that. Let me double-click on it and I put my extended detail view away. Let's focus in again. So what's going on here? Well, we're seeing where we have different things that are being leaked and I have this top level object called my restored data, what's going on there? Let me see, did I not release that.

So there's another use of it, said object from my restore data, set object again, set object, using it to register defaults. Oh, there's no release. OK, so now I need to go and I need to fix that. So let me hit the Xcode button here in Instruments and go back to that code and I'm just going to go and add a quick my restore data release and I will do a little trick here just to get it back on the device, build and install and run it here. And then we'll stop that.

Now another way to obviously, we'll just wait for it to completely terminate on the device. OK, so we'll go back to the run with performance tools menu and we'll say leaks again. This will re-use the existing Instruments document it was using for leaks and now I will go and do the background, foreground exercise again. Do it a couple times, few times there. And we will check for leaks again. Analyzing the process.

Excellent, no leaks. So now I think that the app is in better shape to go to the app store. I should still add a splash screen and continue on with the refinements, but it's better. Now I do want to draw your attention quickly to what is in the ruler bar. These icons here. These are those state transition flags I told you about.

So if I click on one of these, I can see that it will tell me that the reader switched to the background running and if I navigate over I can see when it came back to the foreground and we see all of these state transitions. So that again, is very useful, especially when you go back later and try to understand why you saw a change in performance data that you're gathering. You can say oh, it was in the background and suspended and so that's why.

OK? So that is a brief exercise. If we can switch back to the slides, in using Instruments and how you get around in it. The major controls, the Jump bar, back trace compression, using Instruments to target an app directly from Instruments itself, as well as from the Xcode run with performance tools menu.

And of course, two of the most important I think, Instruments we have, the Time Profiler to see where you're spending your time and the leaks instrument to see if you're leaking any data. So you should get to know both of those instruments. So moving on, I think that in this latest release of Instruments, we have the greatest, the most efficient Instruments ever. And we provide you the greatest latitude ever on how you do you recording.

So first let's talk about what we call immediate versus deferred. So immediate mode is this classic Instrument's mode. You hit the Recording button and instruments processes and displays the data immediately. And what's great about this is that you can tinker with your device, or you're in a game, you shoot off a missile, there's an explosion and you can see the CPU usage spike immediately, you can see the frame rates change immediately. So you it gives you that immediate feedback and you know in that data set, exactly what you want to look at.

But the down side is that hey, Instruments is running on the same computer and it's using some of the CPU, too. So sometimes, especially for sampling instruments, like Time Profiling, you may and this is an exaggerated graph, but you may get gaps or valleys in your data collection. You data collection isn't as packed tightly as you'd like it to be.

So that's why we added a mode we call deferred mode. Deferred mode processes and displays data after the recording is over. So the benefit is, Instruments stays off the CPU, it's not doing anything until you hit Stop and then it consumes and displays all that data. The down side is of course that it's hard for you to correlate that when you, you know, when you shot missile one versus drop bomb, which of those corresponded to the big frame rate drop. So you have to judge what you're going to use. But with deferred mode you'll get more tightly packed samples and data set and that can be very useful when you're looking at something that's very, very time sensitive.

So when you launch your apps, we've had various options but we didn't have them in a very good place in the UI, so we've moved them to the targets user. One of the options is to choose where you want your standard I/O to go. So you can have it go to the Instruments console or the system console or you can just discard it. Maybe you have a very, very chatty app and you don't want the system overloaded with all that I/O, so you can just discard it completely.

And on the Mac, if you have a 32, 64 bit capable app, you may want to run it in 64 bit mode and 32 bit mode, especially if it's using a lot of memory, a large address space, to see how it performs. So you have those controls. In the simulator, you sort have similar control. So you can change where your console I/O goes, but you can also say what kind of device you want the simulator to simulate and what kind of SDK you want it to use. So that's very helpful to know as well.

Now if you're on Mac OS X and you're developing launch agents, agents or daemons, which are little headless services that you can have on the Mac, it's always been a problem to be able to analyze that primordial start up segment of time when the daemon is first hooking up to everything.

A lot of times that can be the most interesting thing to look at. Does it leak any memory right there? You know, what's going on with CPU usage right there? So what we did was connate tightly with launchd, so that Instruments can start analyzing the app as soon as it's created by launchd itself.

This is exactly the same amount of data you'd collect if you'd actually launched an app directly from Instruments. So how do you do this? Well you go to the targets user and you pick the daemon or agent.plist. The plist, not the actual binary. Because Instruments needs to read that plist and find out some things.

Then you hit Record and you'll get a dialog like this on the screen. Basically Instruments is saying, OK go do whatever it is you have to do to tickle launchd to launch your daemon. Maybe it is connecting up a network or creating a file somewhere or something of that sort. As soon as that happens, this dialog will go away and Instruments will start recording right away. So you've gathered all that critical data.

And let's also talk about wireless, for the phone. So it's possible for you to actually use Instruments, to profile your apps running on the phone, without being connected to USB. So why would you want to do this? Well it frees up the USB port if you're an accessory developer. Let's say you're developing something for an automobile manufacturer, some docking station or something of that sort and you want to see the performance of the app when you connect that accessory up.

Or let's say that you're a game developer and you're using that accelerometer and it's a real pain when you're testing your game aggressively and that cable is slapping you in the head as you're moving it around and or it's in your way as you grab the device and making it very awkward. You just go wireless. Disconnect it from USB. It's much easier to do.

Now there's one thing that you need to remember when you go home or go back to your workplace and you try this, if it doesn't work the first thing you need to do is make sure that you have Bonjour multitask enabled, on your Wi-Fi point. If you don't, it's not going to work. Now to find out how to do that, just refer to the standard Bonjour documentation. There's isn't anything iPhone- or Instrument-specific about that.

So how do you enable this? Well, you hold down the Option key while you go to the targets user and you'll see your device appear, but it'll have Enable Your Device Name Wireless. So you select that and then you'll see your device appear but it will be kind of grayed out. Because it's handshaking with your machine and getting everything set up and a second or two later it's ready and then at this point you have not one, but two Instruments daemon's running on your device. You have one dedicated to USB and you have one dedicated to wireless.

See you don't want that because they're both using resources. So you want to unplug your USB and when you do that the USB-dedicated Instrument's daemon will go away, you'll see that item disable and now you can just go completely wireless and you can do everything you can do with Instruments normally over USB, wirelessly. Of course your performance will vary based on the performance of your Wi-Fi hotspot, etcetera. But it's a very handy thing to do.

Now when you want to disable this, because again, it is taking up you know, radio resources and it's not quite as fast as USB. Just hold down the Option key, go back to the target chooser and the menu item will change into Disable Your Device Named Wireless. Select that and it will go away. At this point, the only way to get it back is to connect up USB, so that you can re-enable it.

Another way to disable it is actually to just reboot your device. And so now we'll just do a wireless demo. I really don't think so. No wireless demo, not today. Actually I did have a slide for that, but not today any longer. So let's move on to symbolication.

Well Steve, wireless, Steve. So often when you take a trace, it has to do with your own code. There are instruments actually in the app that don't have anything to do with actual code, but most of them do. And what's very critical on that is to have Instruments be able to switch those hex addresses into real symbol names, like a function name. In order to do that, Instruments will look in SDK paths to find a symbol-rich data and it will also use Spotlight to look it up.

In order for Spotlight to help us find your symbol-rich binaries, you need to make sure you build your app, whether it's for the phone or for the Mac, DWARF with dSym file. So just go to your debug settings and probably, it might say DWARF, switch it to DWARF with dSym file. Now, if you do that, you need to still make sure that it's visible to Spotlight. Spotlight won't look in any encrypted disk image and you might have Spotlight already set to not look at certain volumes. So you need to make sure Spotlight is looking in that location.

Now if you don't have any symbols, maybe someone else took a trace, they didn't have all the symbol-rich binaries and they handed it to you or you did find yourself in a situation where, pardon me, where Spotlight could not find the binaries. You can always resymbolicate them after the fact. It's very simple to do. Go to the file menu, select resymbolicate document. You'll see a sheet pop down.

You select the paths that point to the right symbol-rich binaries or directories and we'll recursively look in all those and then you just click symbolicated. It's that easy. Oh and turn all the hex addresses into symbols. And then I'd like to make one note about tracing, using Instruments against apps in the iPhone 4.0 SDK, just because it's hit us.

We've all got accustomed to this, so I hit the Home button, my app quits. Instruments stops if I was tracing with it. But now it may no longer terminate the app right, the app may just go to the background and Instruments will dutifully keep tracing. So what you need to do is just get in the habit of stopping the app from Instruments itself. Pressing that Stop button.

If, another issue that you can run into is that you're actually debugging your app and you hit the Home button and you forget you did that and you try to trace with Instruments and Instruments is going to put up an error saying the debugger has control of this process. So what you need to do is also remember that when you're using the debugger, to hit the Stop button as well before you use Instruments against the same app.

So we've made various improvements to our existing instrumentation we've had for a while and I want to go over those improvements. So first is Time Profiler. This is for both platforms and it's the most efficient time profiling mechanism by far that we have. It does everything from the kernel. Takes its samples in the kernel and you can use it in two ways. By default, you're looking at running threads.

So you're just looking for code that is running but it's not running very efficiently, so you want to find those hotspots. But you can also use it to track down and all thread states mode. You go to its inspector and click All Thread States. So it can find threads that are blocked. So maybe you have a choppy app or it's deadlocking somewhere, you switch Time Profiler to All Thread States and you'll find those threads as well.

And of course, it can also see all processes on the system, not just a single process. So that's really nice when you want to see you know, what in the world is going on in the system? Why is it so slow? You use all processes and you can see who the guilty party is.

So we've also added kernel frames to the back tracing and call tree Time Profiler. And we did this in a really cool way. Because you can see, but logical way, you can see the user space stack frames, but in a continuous line then you see the kernel space.

So you see yourself transitioning all the way from user space, into the kernel and maybe into some kernel extension. It's really kind of far out to see it when we finally put that together. It's really awesome. If you're a kernel extension developer, it'll be really important to you. And of course, Time Profiler, as we saw a moment ago, is also available on the iPhone 4.0 SDK.

And it's far more efficient than CPU sampler that you were using before and it doesn't really seem intuitive, but deferred mode really matters for tracing the device as well. Now of course, when you're in immediate mode on the Mac, you have Instruments running and you have your target process running, obviously they're fighting over the same CPU, but the reason that it matters even on the device, when Instruments is still running on your Mac, is that if you're in immediate mode that Instruments daemon on the device has to take that data out of the buffers we're collecting it in, package it up, send it over the wire, over wireless and all that takes cycles.

So it makes a big difference by putting your trace in deferred mode before you take it for the phone as well and significantly proportionately more than it actually makes on the Mac and that will hold on to those data buffers unless we fill them up, in which case we want to get rid of them, get them onto the Mac, so we don't constrain the memory that your own app needs or you hit Stop on the recording. So deferred mode really does matter, even for device time profiling.

So we've also added a new instrument called HeapShots and HeapShots, well actually it's a feature of Allocations Instruments, pardon me. HeapShots will actually allow you to track down what we call abandoned memory. We call it abandoned because it's not leaked, but you allocated it, maybe you used it once long ago and you basically abandoned it. You forgot all about it. There it sits, still referenced, you run leaks, you're not going to see it but it's taking up space until you quit your app.

We find that this can be an even more serious problem than leaked memory and if you have an app that maybe you didn't first develop or that's several years old, this will start to build up. Because someone, somewhere, wrote some caching routine for a feature that has since been removed, but no one knew about the caching routine. It's been dutifully caching away its memory and not being used at all. So that's a waste.

So you want to, you want to analyze your app using the HeapShot technique, to find that abandoned memory. We also have VM tracker. This allows you to look at your VM usage of your app on the Mac, in the phone. And again it's part of allocations template, as a separate instrument.

You can identify, it identifies reasons by tag and you can look at things like resident and virtual size. And this is great to use against a Core Animation app or something where you're loading images off a disk and you can associate how much memory that's taking with the actual file on disk.

So that's very cool. So now I'd like to demo, just a few advanced recording techniques, take a look at immediate versus deferred mode as well and see why that matters for you now. So if we can switch to the demo machine please. This will be just a Mac demo.

OK. So let's start up Instruments and we will launch the Time Profiler instrument. I'll choose the Mac version there. And let's look at a little app that, that was written a long time ago called the GL Mech app and we're going to first run this in immediate mode. We'll get this guy going here and let me bring up Terminal and let's see how much CPU instruments is using right now.

So Instruments is using, here it is, it's going to bounce around between 4 and 7%, depending on what's going on as the GLUT Mech app runs. So 4 to 7%, so let's quit the GLUT Mech guy and let's go up to the file menu and let's go to deferred mode. And let's run our little guy again. Now this darker appearance in Instruments is deferred mode. So when you see that, that's why.

And let's go and look at top again and let's look for Instruments. Now basically, other than a burp here or there, Instruments will stay at 0% for long, extended periods of time. So this makes a significant difference as you're analyzing some very CPU intensive application. So that is immediate versus deferred mode. That's an important question that people have had about CPU usage and so we thought we'd answer it now.

Another thing that people have wanted to do, they'll ask me, how can I precisely time filter my data between two points. Say when call A was made and call B was made or event A happened and event B happened? Well there's a couple of ways to do that. A sort of really poor man's way of doing it is actually tagging it with a console. So let me run the GLUT Mech guy again and we'll say, go and stop, go, stop, go, stop. So let's see how we could time profile between a go and a stop.

If I go down to my console here by using the Jump bar, I'll select Console, we can see some console API output that I had added to that app, to just say starting animation when you hit the Go button and stopping animation when you hit the Stop button. It's very simple.

But what's interesting is that, the both the console and its left hand margin and the timeline view, both have timeline inspectors. So if I zoom in on that and I take the inspection head in a timeline, I can see that the inspection head in the console move around to where that actually happened. And if I move the console.

I can drop it and it will move to where that is in the timeline. So let's say on this second starting animation, I want to begin a time filter here.

Obviously this is something that you'd do after the recording is stopped, otherwise you know, the data is going to be changing and driving you crazy. So I can use this inspection range tool bar item along with that, so I precisely move to this point in time by selecting this location in the console and now I'm going to click this left hand Inspection Range button. Now what that's going to do is say, begin a time filter from this point on to the end.

So I'll press that and now it's filtering it from that point on to the end. And now that that initial event has been filtered out as well in the console and so now I'll move to my, to my next stopping event and here it is. And now I can use this right hand side button in inspection range and say OK now stop the time filter there.

I'll do that and now I have a precise time filter and I can go back to my sample list or my call tree and all this data is filtered within that time range. So it's pretty precise. But, on a system that's really loaded down, that I/O is not really going to come out exactly when you emit it and so there's another better way to do this as well.

So if I, I'll zoom out here, what I can do is I can use dtrace and this will work for the Mac, both for Mac apps and for simulator apps. So if I go up to the Instruments menu and I say trace symbol, it knows all the symbols it's seen, so I can say start animation and I'll add a probe point for where start animation is really actually called.

And remember, dtrace is managing all this from the kernel so it's going to be really precise and I can do that as well. There's a command accelerator for that, so I can just say command t and I can say, stop animation. So now I have dtrace probe points for starting and stopping animation. So now let's go ahead and run the GLUT Mech app again and let's have it do some things.

Go, Stop, Go, Stop, Go, Stop. And let's quit. And now we see that in the other dtrace instruments, we see these are basically representing how deep a stack was, but there are points and explicit events where these events actually occurred where it actually started animation and stopped it.

So now if I want to filter, I'll just click on my start animation instrument first, I'm going to use the inspection range again to select the first event here. Now we're right lined up and I'll start my time filter there and then I'll go to stop animation and it's conveniently moved the inspection head to the first location. Stop and I'll use the right side of the inspection range there and now I have a really, really precise time filter.

If I go back to my Time Profiler instrument and select and have the call tree review or look at samples list. All this data is going to be precisely filtered down to that time range. So those are very useful techniques for how you trace data and how you look at it. Now this is, this is a pretty neat little set up I have here.

I have set the recording mode to deferred, the default mode in Time Profiler is immediate and I have added these probe points for starting and stopping the animation. So I'd like to reuse this and I can by making this a trace template. So I can go over to the file menu and say Save as Template, a sheet will pop down and this directory that it opens up to is in your user account. Library Applications for Instruments Templates. And I can say, call this you know, my cool template and add a description, choose an icon or something. This is fine for me though and hit Save. And now both Xcode 3 and Xcode 4 are aware of that template.

They'll look in that directory and Instruments of course is aware of that template as well in its own user section of the template chooser. And now I can reuse that over and over again. So those are some techniques for doing a performance analysis and the difference between immediate and deferred mode and I thought you would just find that useful. So let's just go back to the slides.

So we also have some new instrumentation in the latest SDK.

One of the things we've added is the Energy Diagnostics set of instrumentation. This is a large grained measuring technique to look at energy consumption of your device, with or without your app running on it. It will measure battery power, the CPU usage of your app, as well as other important services on the phone like media services. And it will track the on and off state of vital devices that consume energy, the screen being a really big one and Wi-Fi and Bluetooth, etcetera.

We also have another really cool new instrument called the Automation instrument. This is totally awesome. You can actually use it to automate and exercise your app. So you can simulate clicking on various controls in your iPhone app and if you use it in conjunction with say another instrument, say leaks and then you run, you have some, some set up where you run this before you make each submission or an internal release or before your GM, you can check for pass/fail messages and other results, via the JavaScript that you write with this instrument, use with this instrument. And then you can store those results away in some separate database perhaps and you can just export them as comma separated values for example and then refer to them later on and see how you've been progressing in your QA testing.

There's also a really cool OpenGL ES Analyzer instrument. This is really amazing. It can actually, of course identify just bottlenecks in your own code, but it can provide you actual advice, recommendations as to how you can improve the performance of your GL app, which is just really cool. It just comes out in English and says hey, you're doing this and you should be doing this other thing. So it's a little expert in a box for you.

And finally, let's move on to our really new instrumentation, the Xcode 4 developer preview. Namely system trace. So this provides you with comprehensive information on the entire system with one or more processes, looking at thread scheduling, why they're scheduled, how long they stay on a core. And you can look at system calls and VM operations, etcetera.

The system trace template is made up of three individual instruments. The scheduling instrument, this tracks threads, contact switches, the reasons why, the tenures, how long they're on. The system calls instrument, these are calls into the kernel from user space. And the VM Operations instrument, so you can see page cache hits and zero fills and all sorts of cool stuff there.

And also, system trace is the first set of instrumentation really that takes advantage of a new feature in Instruments, called the highlights view. So system trace especially, can just record a ton of data, but we have other instruments that can do that too. And it's, it's a real labor sometimes to have to be able to sift through all of that data, looking for the problems, especially when you have to correlate a lot of data together.

So with the highlights view, we take all the key statistics, the very core statistics and we summarize them in little graphs that show you that the top five or so extreme issues, such as processes or contact switches or something, and you can quickly key in on that by looking at those graphs to see where you really want to dig in, rather than just in looking at all the data then just you know, becoming bleary eyed at all, everything that's presented to you.

So I have one more demo. It's a pretty short and simple one. But let's go to the demo machine and take a look at system trace.

So, as I said, I have the developer, Xcode developer preview installed as well, so I'm going to launch that version of Instruments now.

And I wanted to show you what system trace can tell you about and visualize for you, as to why it seems so simple, but why an apps performance is degraded when some other app is doing something intensive. So let's look at system trace and we're going to look at all processes here and I'm going to open up a couple of apps here. A little app to scale down images to create Mip maps and our little friend the robot here. Let me get these guys going. Now the previous version of that, that robot we saw, actually put a sleep in it.

Because it made me nauseous to see how hyper this guy actually runs. Apple had this example a long time ago and it used to run very smoothly because machines back then were a lot slower. Now machines are so fast it looks like it had a bit too much caffeine today. So, but I want to show you now, that the change in performance when I start my Mip maps app. So this is going to use a lot of threads and be pretty intense.

And it's slowed down dramatically and we can see the reason why if we actually trace this with system trace. So I'll start that app in deferred mode here and I should have actually started that before I hit that button there. So we'll take some data and that's enough and, this is a MacBook Pro here. It's just a couple cores and it's gathered just a ton of data so it takes a little while to process that, but luckily it's doing it deferred. So now let's quit our two apps here and let's look at what we have real quick.

So if we go to the highlights view, we can see and we'll expand this, a chart of what's going on and we can look at the top here, at the Scheduling instrument and if we look at process contact switches and what's going on up here, a great deal of threads are being switched on and off core. So there's far more threads that want time in this scenario than there are cores to service them.

And if we, if we click on one of these charts, say process contact switches, we can see that the Mip map utility has had a huge number of contact switches, but GLUT Mech which is a purely single threaded app, has a lot of contact switches too and if we use the little Focus buttons again on GLUT Mech, we look down and we go again to all thread states and now we can or all threads and we can see how this Jump bar has developed.

We were in summary view, process summary, GLUT Mech threads and then thread tenures and we go over to this reason column, we can see a lot of preemption and blocks. So this poor little robot was having a hard time running on a system with so many other things going on demanding time of the cores. So I just wanted to show you this example because it demonstrates how you should use the system trace. You need to be aware of and we can go back to the slides, aware of the system you're running on.

It really is a system trace and so one of the good things to do with it, when you've made sure that you have the state that you want to reproduce in the system, is to run say a heavily multithreaded app on a two core machine and an eight core machine or a memory intensive app on a machine that has very little memory and one that has a lot of memory to see how everything then works together to give you or degrade your performance. So that is a demo of system trace. And so in closing, I'd like to just say that we strongly believe you know, that Instruments is your go-to tool for performance analysis and it clearly has more capabilities than ever.

But I hope it's still in a way simpler to use and it does provide more accurate insights than ever from what's going on in the kernel all the way up to user space. So, there are many sessions following this one throughout the afternoon and the rest of the week that I strongly encourage you to attend, that will be using Instruments in one way or another or demonstrating, specifically, how you use Instruments for memory analysis, CPU analysis, etcetera. And if you have anymore information, please refer to Michael Jurewitz and developer tools evangelist and the documentation online, as well as the Apple Dev Forums.