---
title: WWDC2001 Session 121
framework: wwdc
role: article
path: wwdc/wwdc2001-121
---

# WWDC2001 Session 121

## Transcript

Kind: captions Language: en welcome to session 121 you know performance is an important consideration for all of us and at Apple we're certainly doing our part working hard to improve the performance characteristics of Mac OS 10 many developers have told me that they've seen measurable performance boosts in their carbon apps running on 10 but we know there's always room for improvement and so it's my pleasure to introduce the manager of the advanced Mac toolbox team John Orochi to tell you about how you can improve your performance running on Mac OS 10 welcome John [Applause] good afternoon perhaps you've noticed there's been a little bit of an undercurrent a theme here throughout the conference on performance and basically a lot of that revolves around a realization at some point you've carbonized your app you've you've taken advantage of some some of these latest features and you're comparing your app on a nine and ten and you realize gee this part of my app is slow why is it slow and there's been other other talks that have khanna ghanna over the high level a description of why it's slow but basically we've seen time and time again as more and more people bring carbon apps to ten that there's this basic assumption that that certain code certain code paths or calls will have the same compatibility on OS 10 as they do or not we we looked at all of the api's going into carbon we studied them carefully we knew right up front that there were several api's that just would not be would not work well on 10-4 technical reasons we also knew that there were some api's that would pose performance problems we kind of had that had to compromise between getting all the best api's into carbon versus making sure that you could get your apps over to carbon readily and so the ones the api's that we knew wouldn't perform very well we still left them in carbon so you could port your apps easily and we concentrated on providing alternate api's so that you could actually eke out the last bits of performance with your app before I actually get into some of the specifics in this session I just want to mention that this session is coming ahead of the tools talk 705 which is later on 5:00 o'clock this afternoon and this sessions going to refer to tools that are described in depth in that talk ideally we would have actually been able to schedule the sessions that one coming after this one but I'm going to make reference to these tools I'm not going to go into any depth just know which tools are appropriate to certain techniques and tips that were talking about here and then go and learn about the tools in the follow-up talk then finally there's no one answer for performance and there's going to be all sorts of different performance problems with your apps so look at--look to in other sessions as well some of which have already happened for tips on performance in your app okay so these are the topics that we're going to go through today and they're pretty much ranked in terms of the way I would prioritize and for you if you're only going to do one thing with your app regarding performance I would definitely look into application launch I'd highly recommend the first three going through launching filesystem usage CPU usage that's where you're really going to get a lot of payback in terms of the time you put in but all of them have interesting performance benefits and I really would encourage you to really try to get performance into your planning into your scheduling and into the way you're develop your app so let's start with application launch perhaps some of you are familiar with the bouncing icon the interesting thing is that sometimes it bounces quite a lot sometimes it doesn't stop bouncing there are there are pretty good reasons for that first of all the the bouncing is there as visual feedback to the user that something is actually happening that a launch is occurring right some very legitimate reasons why the app may take a long time to launch is perhaps the app is actually off on some network volume and the network is sluggish perhaps it's on a disc that is spun down others it may be on a CD drive there's real legitimate answers to some some of these launching performance problems but those aren't really interesting and they're not really under your control right there's kind of environmental the one that we really want to talk about today are the the things that you can do something about so when talking about app launching I like to refer to two different kind of launches to different environments and once you app in which you launch your app the first one being a cold launch and the second one being a warm launch a cold launch is it's your app on launching on a bad day everything is going against your app all the files that it has are not readily available or cached in the system all the memory that it needs is has to fight for some some of that memory if some other app is using it this is kind of a worst case scenario and it's actually it's an extreme that you're not really likely to hit as the system is actually being used but what we do is we mimic this a simple way to do it is is to basically write a tool that allocates all of physical memory then touch that memory and then I'll flush out all the memory that's in the system and then see how your app launches after that that doesn't quite cover all of it because there cases where even though the memories is no longer cached you actually potentially have files that have been cached in the file system and other kernel objects that affect the performance so it's actually hard to get to your real worst case scenario warm launch on the other hand is is basically things are going well for the app the libraries that you depend on are all loaded they've already been instantiated the best case is basically it's an app very much like yours or another instance of your app has just launched and the reason I distinguish between the two is because they're they're really different in terms of how you optimize and the the biggest point is the the cold launch is predominated by what I would call low-level I know and I'll explain that in a little bit so my challenge to you is to get your warm launches for your typical app and this will vary depend on a memory and disk and configuration to launch in one bounce there are apps on OS 10 that launch on one bounce in this situation and there's plenty of improvement for even the apps that we've shipped in the first release of ten the other thing I would encourage is - measurement techniques that help constrain or help give you boundaries as to how fast or how slow your app can launch the first one what I refer to that as the do-nothing app is take your application and the very first thing you should do right after in your main entry point is just put in exit to shell leave everything else the same exit will work as well what you're trying to do here is launch an app that basically does nothing but not just any app your app with all of the libraries that it depends on everything else is the same it's just you're not executing any coded initialization I think you'll be surprised when you actually measure that with either a stopwatch or any of the tools that we have on the system I usually use for this case I usually use the time command at the command line it's an interesting data point because it's when you first look at it that's your best case right and a worm launch when you just do absolutely nothing at main that's as fast as you're going to get well actually that's not quite true because before main is run there is other code that run runs that you actually have some control over particularly there's the init routines of your libraries that you pull in that execute code there's the init routine of your your app itself that executes code and the third major category is static initializers for c++ these three areas are things you definitely have to look at because that they contribute to your best case scenario you haven't run any code in the app at all so you may be doing things in your static initializers that you just don't even remember you put there right so make sure you take a look at those so that's the do-nothing app approach and that's a good data point to capture the other one is more like the best case just to kind of get an idea of how how good things could be and there I would just recommend that you you basically have a very high-end system as much memories you can put in it make sure that absolutely nothing else is running take it off the net launch the app once and launch it again measure it those are two boundaries that you should keep in mind as you do performance analysis of your app and what you should be doing as you improve your application launch performance and see how you can make get those two to converge essentially I'm not actually bringing up a talking at length about some more conventional techniques that that you are already familiar with there whole area of perceived performance is something that you might also to look into I'm talking about real-time performance talking about clock time there's still definitely advantages to for example putting a splash screen up ideally you'd want to put your first window up as fast as possible and if you can't get to that to be as you know a second kind of granularity maybe a splash screen is in order some feedback oh the other thing I forgot to mention on the bouncing icon the bouncing icon starts when you double-click on your app it stops when your application is handling events so if you're doing a whole bunch of other stuff before handling events you're not able to respond to events that's going to tie into this it's going to tie into how it's perceived that your application launches it also is going to tie into how when the user can actually use your application and then there was one other thing on the bouncing app is it will timeout after some absurd time and then at that point the user isn't quite sure if the app is actually launched or not okay so in looking at launch performance I was able to profile to word processing apps this is a typical profile of an untuned app you can see the the time is dominated by low-level i/o by that I mean the virtual memory system paging the dynamic loader doing library loading initializing libraries for the first time this is largely completely out of your control this is something the OS takes care of but the other two sections are really interesting that being the file i/o and the CPU time during launch by file i/o the tip a typical example of file i/o is when you're actually going and reading preferences maybe your enumerated plugins that's the kind of file i/o I mean on the CPU side of things it could be as simple as determining you know maybe you've read your part is in and now your your sanity checking them anything that's typically compute bound now what's interesting here is those two file i/o and CPU time compete with the lower-level i/o the ideal case we minimize the file i/o and CPU time and we can make up much better use of low-level I own the other thing that sometimes shows up in untuned applications is pauses by that I mean either an explicit call to a call like delay or a sleep call left in accidentally left in to work around some bug those are kind of hard to detect usually you have to see that basically the app is running but it's not doing anything compute-intensive and it's not doing i/o there's a couple tools that that I'll get into a little bit later that'll help find these these kind of problems the other anomaly we see sometimes is writing during launches there's really no good reason that your application has to write to the file system during a launch now I'm not talking the first time your app ever launches on that system for that user it's perfectly okay to go ahead and write out your preferences for the first time but statistically speaking your typical lunch should not have any file system rights the reason for that is first rights are much more expensive than reads and the whole launch facilities the low-level i/o has optimizations for reads it's basically geared at reads and the write right in the middle app will interrupt it will essentially discard some of the optimizations here's the profile of a tuned at now both of these are what it referred to what I would I explained before as a cold launch this one you can see has a lot more low-level i/o and that's good because that's the best case for us we can optimize that into the largest chunks of i/o that we can do and we can do them as efficiently as possible um of course the file IO and the CPU are minimized in this case if this were a worm launch all that low-level io would go away you might see some more compute cycles but the profile is quite different for a worm launch okay so what does that mean for both cold and warm launches you should concentrate on CPU usage and filesystem usage that's the area's that'll pay back the most the best way of doing that is is first do only what you need to do look at what you're doing in the launch of your applications if it's the typical app you're probably initializing a whole bunch of stuff that you may or may not use during the life of that app right look at deferring some of that initialization this might be a very good use of setting up a carbon event timer to descend yourself a one-shot timer to defer some of this initialization or don't even do it when the app is up and running events do it when the user first uses that feature of your application particularly if the feature in question is a somewhat optional feature not saying it's a bad feature or anything I'm just saying if your typical user base isn't going to use that feature why pay for it why pay for it upfront and your initialization then the second speed up tip I would have for you is eliminating some of these things that you see during launch just outright eliminating writing and pausing of some sort that's a good a good example of that dead code make sure your tools are working for you in this regard I'm talking about dead code that you know might be in there for debug reasons may be in there for whatever reasons you have for tracing filing things like that make sure that that doesn't end up in your final product just a little bit of code sprinkled around means it affects your locality means that code that would not be on the same page code that should be on the same page would potentially be split up across two pages and that can make a difference then there's another kind of dead code that I would encourage you to go after that's the dead code that you've inherited over time now is the time to get rid of that kind of code that's checking to see if quick-draw supports color no need for that anymore you probably still have the check in your code you probably still have the code base that supports that check at least pound to find that out if you're your app and then of course redundant i/o and I shouldn't be understated redundant i/o is where you can actually get a lot of time back from your launches and now I'd like to bring up neat and ghen entre who's going to go through some of the details of file system performance and help with that rate redundant IO [Applause] this on ok it's on now good afternoon so as John mentioned redundant IO and in fact any kind of file IO is a big burden on clock time of your application doing anything to get rid of this file IO or minimize it at launch will pay off immediately and it can either pay off at least minimally in reducing system call overhead in the best case scenario where you've got buffer caches that have got your data and they're already hot all the way to if you're reading something off of a network disk and you solve because it's on a network so here are the areas that I'd like to cover first is file iteration metadata volume iteration well actually you know you can read those let's just get right into it first one the venerable PV get cat info you're all familiar with this call I'm sure and when it when we were creating the carbon API it was pretty much no question we couldn't get rid of PV get cat info it would have just caused a huge upheaval in people's source bases everywhere ours included and so there was just no choice we had to provide it it had to be compatible unfortunately we couldn't make it performance compatible but that was a secondary concern in the interest of getting your apps onto 10 quickly the bad news is the PV get cat info is non optimal on any file system that goes for 9 and for 10 if you have file sharing on on 9 for example and for the most part it's overkill for all clients PB get cat info just returns a huge amount of data and the developer code out there that uses PB get cat info ranges from using none of it in other words just checking an error code to maybe one field from this enormous data structure let's take a look at that data structure in fact I couldn't even fit everything that get cat info returns to you it's just an enormous amount of stuff and you know when it came time to or back when PB get cat info was first created and exported as a system call it made perfect sense because it was a it was a great reflection of the underlying volume format right on HFS discs the catalog information is stored in one section of the disk it tends to be hot in the caches because everyone is using the catalog files so PB get cat info tends to be free and well while us while you've paid the trap overhead you know on a classic Mac OS system while you've paid the trap overhead of making the call and getting into the file system and what-have-you let's just return back everything that we possibly can and guess what we did of course and and everyone uses this call it's plenty fast on nine there aren't any real problems with it problem slowly started creeping in with file sharing again and things got much worse with ten sort of as Nixon as a graphical example of how people get CAD info works this is on an optimal this is an optimal case right here this is what file sharing turned off this is you know on an HF S or an AFP disk in other words all the data that's given to you in one PB get cat info call is in one contiguous part of the disk and lo and behold it fills in the parabola in one shot again this is optimal let's look at what happens with PB get cat info on other file systems with Mac OS 10 now we have the opportunity to support plenty of other file systems then than we ever did before and it turns out that PB get cat info is just not a good reflection of the underlying volume format in order to get some data we have to go to parts of the disk different parts of the disk and in fact a lot of those different parts of the disk are completely disjoint which means you make one PB get cat info call on one of these file systems you're doing numerous IO operations and I don't think I have to say that that's bad potentially if this is a network-based disk and as we move forward more of them will be fortunately there is a good solution and it's available on Mac OS 9 and later the call is FS get catalog info the interesting design point of this API is that it takes a bitmap that allows you to specify exactly what fields you want returned to you again FS get catalog info I didn't put a slide here with the fields that it returns but it's a big honkin per Ambler Slyke PV get cat info but it does take a bitmap and so whatever you're interested in you can fill in those bits and FS get catalog info we'll do the minimal IO required to satisfy your request now I can't emphasize enough that you have to pass in just those bits that you're interested in if you go ahead and fill in the you know all of the bits if you pass in ffff for everything you may as well just use PV get cat info it's not going to buy you much and you're gonna pay the price like we saw in the previous slide a good way to see exactly what's going on as you know when you make a request an FS get get catalog info call to see what's going on either the covers is to use FS usage this is a tool that's on your systems and it will be covered in the performance tools talk I believe it's session 705 that John talked about earlier it's great to actually just write a simple little app call FS get catalog info with the various bits that you are interested in and just see what's happening particularly on these other file systems you know something that's not h FS or AFP NFS or u FS u FS is probably the most readily available so here's a quick little sample give me given an FS Ref tell me if this item is a folder notice that the only bit that's passed to F the FS get catalogue info call is the FS cat info node flags because that's the only bit that we're really interested in so on an NFS or a u FS file system that's all we have to worry about and we can do that in one system call at most in fact in a lot of cases we can do it in zero and calls and then of course the field is ended in return the next topic is volume iteration so when it came time to create the Carbon API we were going through and pruning out a lot of areas that we just couldn't support in the in carbon on OS 10 one of them was the low mem to get at the VCB pointer a lot of Carbon apps or a lot of Mac OS apps saw this as a free way to get access to all volumes to enumerate all volumes with zero i/o and you know I don't have to tell you just in memory copies are very fast very efficient however when we created the Carbon API it was pretty clear that we couldn't support direct VCB access and our recommendation was and continues to be to use one of the get volume info type calls specifically in the documentation we mentioned H get V info however the problem the problems that we have with PV get cat info are the same problems we have with pdh get V info and it tends to be very expensive it returns a large parameter block for most uses you probably just don't care about a lot of that information and exactly analogous to FS get catalog info there is an FS get volume info call again passing the minimal bitmap that you require and we will do the minimal i/o in a lot of cases it will just be an in-memory copy for us out to your parameter oh I owe the FS ref ap eyes are the primary ap eyes and the preferred api's in Carbon on OS 10 in fact all of the major clients of the file manager on OS 10 today the file manager navigation services and cocoa open save all use the FS ref API and have actually seen huge performance gains in doing so we've seen performance gains not just on HF on on NFS and network based file systems but in fact we've seen them even on local HFS discs so it's def at least something worth investigating so on to file i/o first thing I'd like to plug here is what some of you probably recognize as being a relatively old tech note I think it was put out in 93 or 92 I'm not really sure plant manager performance and caching turns out a lot of the lessons that are taught in that tech note are relevant today and I highly recommend that you go back and read that some of the biggest points in it of course are to use large page lined i/o wherever you can if you're picking through little bits of data in a file don't push that down to the file manager or the file system and you know don't pay the system call overhead just because you're doing little bitty writes do larger page lined i/o in to preferably page lined buffers and you'll get the maximum throughput from the file system a lot of times without even having to do copies from the kernel buffer if you pass us page aligned buffers as well again let me put in another plug for FS usage this is a great place to look and you can actually see exactly where reads are coming through rights are going through and how much data is actually being read her read or write this will help you identify quickly where you're spending a lot of your time doing up doing a lot of small iOS the next point is don't pollute the cache this is covered in the performance tech note and it's something that a lot of clients overlook and it really shouldn't be because it tends to pay off in big wins what I mean by not polluting the cash is you as the app developers know exactly what your usage pattern is going to be for any bit of data or large chunks of data you know that if you're streaming in if you're importing a file that you're just not going to look at again say you're importing from some foreign file format into your own internal representation you're just not going to go back to that file again to do the read and if you're talking about a multi megabyte or or you know it doesn't even have to be that big multiple hundreds of K file if you just do reads without passing the no cash mask what you're actually doing is filling the buffer cache with data that you know that you're never going to read turns out that by passing the no cache mask you're not actually hurting yourself you're not hurting your throughput by doing those fresh reads from these files but by actually filling the buffer cache with these blocks that you in fact know you're never going to read you're evicting other blocks other blocks that the user probably cares about a lot more than you care about this imported file and the same goes for write say your say user select save as and you have some whatever you're saving your your internal representation out to some file format that you're not going to read again again you know that you're not going to be doing this so if you pass the no cache bit to these rights you're not going to pollute the users buffer cache and in fact you're not gonna pay any performance penalty by passing the no cache fit you're just gonna make it an overall better experience I think a big reason why this isn't used so often is because it doesn't look like it's a performance game in other words when you go and change your code it's really hard to see the benefit of this the reads that you are doing or just as fast the rights that you were doing or just as fast and if you're not if you haven't evicted pages from the buffer cache that you really cared about you're just not going to notice but it is still very important and I strongly encourage you to to look at to look hard at where you're doing IO and what kind of IO you're doing and pass the no cash mask where you can internally just a couple examples of where we use it or when we're doing find your copies the finder is doing a copy you have a folder from A to B it knows the finder itself knows it's never gonna or it's very likely that it's not going to look at that data again unless the user requests it so there's no reason to flood the entire buffer cache with these copied blocks instead the users data can stay intact and the finder copy can execute just as quickly as it did before the other area is in iTunes when it's encoding a file or or ripping a file from CD and writing out to disk iTunes itself knows that the chances are very slim that it's going to actually go back and read those pages again so it passes the no cache mask and it turns out that because of that they use the user experience on 10 is a little bit better even though it's kind of hard to really quantify that and look at it you kind of just have to know that it's better and know that you're doing the right thing okay writing large files one common technique that has sort of been passed down from generation to generation is when you're writing a large file to first to do a set EOF or an FSF fork size to the final length of the file that you are actually writing and then back up and start filling in the data this has a couple of advantages and this is why it's been done over time first of all it is a good preflight to allow you to know whether or not you have space on the disk to actually do the i/o and then second it's also a good way to reserve a portion of the disk a hopefully contiguous portion of the disk so that when you go back and you're actually doing your rights you know that you're getting your writing to continuous parts of the disk and subsequent reads of that document or that data off the disk will be fast the problem is on OS 10 for security purposes when you extend the file what we do is we zero filled the entire file from the current AOF out to the very end where you extend it and the reason we do that of course is security we don't want some malicious program to run on your disk reserved as much space as possible and then potentially sniff through looking for Social Security numbers or credit card numbers or what have you so this is why we do the zero fill of course it has the downside of producing double iOS in this very common usage of the file manager the double iOS come from first when we do the zero fill of that extended area and then later on when you actually do your write if you write a little app on OS 10 right now that all it does is just create and open a file and then just do a set EOF of a gig you'll notice that before that set EOF returns your disk will be buzzing away and when you go and do a subsequent read you'll see that it is all zero field and that's exactly what I'm talking about we're looking at ways to fix this in the near future but the truth of it is we've shipped this way this is already on customers disks so it's something that you should probably address now and fortunately there are a couple of ways that you can address it you can use the pb allocate call this does not have the zero filling behavior however it does preserve it does allow you to reserve a portion of the disk for a contiguous for a contiguous file on the disk or the other thing you can do is just write just start writing if you're not doing as long as you're not doing set e of's followed by a right you won't get this double i/o if you're just doing writes pass the end of the file then that's enough of a trigger to the filesystem that your that any subsequent reads are just going to pick up that data that was written so we don't need to zero fill and we don't finally file assumptions I couldn't think of a better topic for this they're heading for this slide so I just put this since the beginning of personal computers we've been able to make some assumptions about the the layout of disks and the layout of hardware and usage patterns and things like that and as we move forwards more and more of those assumptions will prove to be false or can prove to be false under certain situations one of these assumptions of course is that your disks or the user disk is locally attached to the machine that all user data is coming off of a local disk all preferences are coming off of a local disk and in fact document directories and things like that are on local disks well networks are getting faster all the time and pretty much right now they are fast enough that in some situations you can actually create a an environment on the disk where user preferences user documents and various other bits of data are actually stored on a network back to disk and it provides lots of benefits in fact we have this all set up at Apple right now where users can log in to their machines you log in in one workstation let's just call it and you can you log in with your username and your password all of your preferences come up on that one machine you can use your documents just as you have in the packet just as you were you know maybe in your office or you know do whatever you want to you get all your same preferences you go back to your office all of your preferences are updated because everything is on the network it's a beautiful thing this sharing and as we move forward it's going to be one of those things that a lot more users are going to be exposed to but it does mean some serious considerations for your applications in other words preferences and documents and things like that are no longer going to be backed by local disk and this can have this gonna have impacts on your code basse that you're probably not even aware of just because when you're coding or designing with some assumptions in mind a lot of times you're not even aware you're making those assumptions and you know you'll tend to do things like let's say oh I know that I'm caching or I'm bringing this data down off the network and I need to cash it somewhere let me cache it in the Preferences directory or let me cache it to a temp file in the documents directory well if those if those directories are backed by a network volume you're really not buying much by caching something off the network to another Network volume or is this is a lot more common scenario when you launch your app and you're doing tiny little iOS to the Preferences file and this has never been a problem because it's a local disk it's very fast well if it's a network disk that's a big window that you can stall in and your users will definitely notice trust me we've noticed at Apple and we've been working with developers where we can to point out what's going on and help them work through it but the best thing that you can do is try to set up one of these Hostel test environments in your own offices and see for yourself one of the best examples of this is to set up an NFS based user directory and login to that user and just double click your app and see what happens or double-click your app with FS usage running alongside and see what happens you'll notice that if you if you're logged in as either a local user or as a network user a lot of times you'll notice a great variation in the performance of your of your app and a lot of that can be attributed to some of these design decisions the good news is that anything that you fix for the network case will also benefit the local case so if you're working off of may be slower media or maybe not say you're just working off of fast media you can reduce the number of system calls that you're making and speed things up even in your local scenario so it's definitely a good thing to look into doing and check the Mac OS 10 server documentation for more details and with that I'll bring John back up on stage talk about watching the application bounce a lot those network director connect network users when you have your system set up that way we typically see two or three times the number of bouncing we do on the local directory it's really something I advised to take Newton's advice on that one okay you've learned all of the details about what you can do to help with your file system performance I'm gonna talk a little bit now about your CPU usage first thing I'd like to say is you're running on a pre-emptive multitasking system but it's not magic it doesn't give you more than 100% of the CPU on a single CPU system it can't give you free cycles a matter of fact basically the gain is that one single thread on that system is not going to take over the whole system it's not going to bring the system to its knees so if you have a hundred threads that all need to run they're all sitting there have something to do even if it's very little the scheduler has to take into them into account that's why we talked about making sure that your threads are blocked that CPU is still a limited resource so make sure when you're using threads or timers cooperative threads that you're taking this into account the best tools on the system to really look at this our top time and CPU monitor CPU monitor you've probably seen in some of the demos I would advise just keep that thing running as you're doing development just keep it off maybe on a second monitor it'll show you very easily when there's a little bit of a CPU peak and you can go in and see is that your problem or not typically that is a great indicator for when you have CPU bound problems top is another one that you could write run because it shows you a little bit more than just CPU usage both of those I would encourage as you know as you're just doing your ongoing development on on your app keep them running in some window has clues to the possibility of a performance problem okay so responsiveness this is the next area after launching file system and CPU usage that I would encourage you to look into mostly things to do with responsiveness you should be able to fix up fairly quickly by just taking a quick look at what your app is doing in with regards to event handling the biggest indicator that you're not doing event handling right is probably that you're pegging the CPU you've seen this in some demos the best and simplest workaround for that is maybe look around if your if your app is showing this behavior if it's CPU bound and during tracking during you know interaction with your UI take a look use sampler which is a tool that lets you actually pinpoint where in your code the problem lies search your code search your code for still down and button and look at how you're using how you're calling these older calls that we really would rather you get off of track mouse location is your friend that's what you want to be using that's the the basic primitive for letting you do all sorts of tracking in the UI that blocks intelligently so after event handling Oh in addition to those tools I would encourage you to look on a developer CD there's an application called appearance sample which has almost every widget the toolbox supports every control you've ever seen go and play with that app run CPU monitor you'll see all of those those controls block well that's what your app should do if you're seeing different behavior in your app it's either a problem in that you've you've done your own kind of handling your own custom control or potentially in the way that you're using the toolbox the next area that contributes to your apps responsiveness you know maybe it feels a little sluggish maybe everything else is looking good your file system performance in your launch is good but when you activate Windows things don't appear as snappy as they do say online that's probably an indication that you have a drawing problem the best tool for that is quartz debug you've probably seen it some of the other sessions it should be in the performance tool session as well because it'll let you see when you're doing redundant drawing when you drawing the same things over and over the other typical pitfall that we've seen is people back buffering that doing their own double buffering further drawing when the system is already doing that for them so make sure you check the port using QT is port buffered and if it is then you don't have to do that buffering yourself that's being done for you the next area on responsiveness has to do flushing because you have a back buffer it means there has to be a time when you actually get those bits in a back buffer to the screen generally you should try to avoid flushing the system will do flushing for you basically on it event boundaries it'll try to do that as intelligently as possible so you shouldn't have to flush the two exceptions two examples of exceptions are when you're doing some kind of animation you want that to get to the screen right now or when you're not really involved with events at all the splash screen case those are good uses of explicit flushing otherwise let the system do it for you another common performance problem area is with regards to the window resizing and this also has to do with the back buffer in the design of the window system on OS 10 and basically our advice there is to try to do this all in one fell swoop with set window bounds instead of trying to use size window and move window in combination that's what that call it exists for to optimize those cases also the other thing that we've seen with regard to windows is pervasive or heavy use of invisible windows windows are generally more expensive on OS 10 the back buffer in addition the overhead the interaction with the core graphic system in the window server you may have Vince invisible windows that doesn't mean that they don't cost anything that manipulating the visible windows isn't doesn't come for free as a matter of fact I wouldn't look into why are using invisible windows it is often the case that you can ditch that window dispose it create a new one and redraw faster than you can by twiddling that invisible window in the last one I wasn't going to put on here at all but I figured I would try some of the tools on and look at various apps a couple days ago and I just happened to notice that one of one of the apps that I use every day was doing file i/o when I activated a window and I just sitting there scratching my head finger trying to figure this out and it's just a bug but this is one of those things that you probably wouldn't notice unless you're running a tool that tells you that that's happening FS usage is perfect for that yeah FS usage lets you basically see the file i/o that's going on in the whole system and a particular app you can filter things out another use if you're really going after file and anything in particular is is sampler which lets you get tie the the usage pattern back to your code okay pulling versus blocking I'm sure you've heard this a lot in various talks I'm going to talk a little bit about some of the more atypical situations in which you find pulling affecting performance way next event is actually pretty typical but the the fallout of using way next event zero is where we sometimes see some problems so just to make sure we're all on the same page here you really shouldn't be using wait next event zero a very simple way to get rid of waiting x event zero so if you have something that you want to do periodically set a Carbon event timer to do it with the frequency that you need and use wait next event very long time now time and tick count that's something that surprised a few of us basically that we did some performance profiling and various apps show up a tick count is taking up a significant amount of time and one of the reasons is that account costs more than Adonis on OS nine but it's also used all over the place and a lot of UI in places where it really doesn't have to be used first of all we're talking about it's something that's very like coarse-grained right ticks sixtieths of a second calling it more often than 60 times a second doesn't make a lot of sense so the best advice I have for you here is to try to use the event system try to use the time stamps that are in events and look at events like that there's often comparisons made to time now and that can get you out of polling essentially four tick count and have it show up in in it being a performance problem another often asked for a bit of information is the volume list Newton went through earlier how to do that as efficiently as possible but I think it's a pretty rare case where you actually need the volume list I would suggest you just get rid of that code altogether or figure out what you really need if you're trying to find out about new volumes or if you're trying to find out about volumes that have just been unmounted register yourself for a carbon event for volume mount and unmount ask the system to tell you about it instead of periodically going out and looking at all the volumes and trying to figure out what happened same kind of thing goes for preference change notifications there is a theme change applicant there is a various new carbon events that let you know about about things actually up on the volume slider I should probably also have another bullet for processes if you're trying to find out what process just got launched or what process died there's a carbon event for that as well generally we've been really looking at the system to try to find out if there's any legitimate need to do polling the answer should be known we're trying to notify you of everything that you might find of interest it's a much better solution on OS 10 so if you guys see things that you're still you still think you have to pull forward let us know about it we'll figure out a better way to do it and on this final note maybe some of you have heard heard this bit in the application packaging and a document binding presentation yesterday we need notification to particularly in the parts of the the system that presents the file system visually so in the finder in nav services in open safe panel those are showing you the file system objects they are not pulling we don't pull so we need you guys to if your participate in this kind of thing if you're an installer or if you're copying files to a place that is likely to be visible to use the effin notify call lepida notify is a ten only API it's in files dot H basically says something happened something changed in this directory takes an FS ref it lets us know that something changed and we should refresh the contents of that directory in any UI elements they care do this intelligently know if you're copying a whole bunch of files to a single directory let us know when you're done with that copy operation not at every file ok resource manager use the resource manager is very tied to the file manager so in in essence I I could just repeat what Newton said earlier about the files file manager but it's actually worse in that the resource file format was designed way before BM systems were really commercial like they are now and really the file format is not designed in for a VM system in that there's a resource map in one part of the file and resource data and the other part of the file and there's no way around going to both places every time you need data you're asking for a resource you have to go look up where the resource is in the file in the resource map that's at least one IO then you got to go to where it it told you the resource was that's a second IO okay that's bad enough then you look at what's in the typical resource file and you see lots of little resources that's also bad right you already heard how we really like to see very large items that's the ones we optimize we get the best bang for the buck at it so if you have any tools or if you have in the past done any kind of coalescing of your resources if you have resources that for example stur resources that could be combined in the stir pound it's a much better a use of the resource manager going and reading eight bytes out of the resource managers about one of the most expensive kinds of IO you can do the other thing that we see with regards to resources particularly in the use of plugins is numerating your plugins opening up their resource files to find out something about them opening and closing the same files this pattern that we've seen and we really like you to avoid that perhaps what you can do is cash that and open you know cache the results in one file and open that minimally make sure that you just do that scan once when you actually have to find out about your plugins and then for historical reasons just lots of calls to update res file which writes out the map and the data for your resource Forks just kind of call it willy-nilly it's more like a flush in front people's minds and that causes IO okay the last bullet item on here is something that we added to OS 10 basically a feature in the resource manager to kind of help out with these sets of problems the what we did is add a new key to your info.plist called CS resource file mapped and if you set this it's a boolean key if you set this to true it'll change the behavior of the resource manager with respect to your applications resources what it'll do is it'll open them up read-only okay you can't write to them and it'll file map them and then there's some support in the memory manager to support file mappings so that we don't have to allocate for the data that's in your resource fork which saves on your memory footprint and because it's all file map now we get a lot better characteristics of Io because yes we're still hitting that resource map and we're still hitting the data but there's some locality there when we go to the resource map the second time it's likely to be on the same page and when we go for data if you're going through the data of a certain type this will depend on the the organization the data it's likely that we're going to get some good win there the only caveat to this and the reason why we didn't turn this this behavior on by default is that it'll break some of your code at the point where you say yes turn this on then all of the resource handles that you get back essentially the pointers in them point to read-only memory if you try to modify that your application is going to crash so there's plenty of folks who've just turned this on and don't write back to the resources right I mean in general particularly the application resource file you probably don't want to write too because it might be living on a CD it might be reading on a network volume that other people are using in general it's bad practice but let's say you were writing things to the resource but not actually flushing them out to file you can still do that by detaching the resource thereby getting an mm coppy mess with a copy and everything else still works correctly so this is something that you have to turn on yourself and it's fairly straightforward to debug because it basically leads to crashes and if you have any questions about exactly what the info.plist is I would recommend looking at techno 2013 ok the next section is memory usage this can be a real big problem on 10 largely because of the big difference in between the memory models and that you just have a very large and sparse address space for example just right off the bat you could accidentally allocate you know order magnitude off what you intended to allocate and not even know it the system will give it to you mem full errors are relatively rare on this system and that can be a problem so in order to keep on top of this I really would recommend getting familiar with both the leaks and the Malik debug tools leaks in particular you want to keep an eye on you may not notice the performance necessarily so much in your your app it may be that a slow leak over time but it really does affect what's going on underneath the covers in that you know you don't get reuse of the same memory blocks and it'll lead to paging it'll lead to general bad character a ssin so it'll lead to your app generally feeling sluggish aside from leaks I would really recommend that you get a good handle on the size of your application particularly make sure your tools are doing the work that they should for you make sure that things that are actually constant in your application end up in the right section so that they don't get so that the OS takes the maximum advantage of that we went through a lot of the carbon frameworks early on and got a lot of gains by doing this basically marking strings and other constant sections as constant so that they could show up in a text section that gets shared across the system same thing goes for your app the third thing on memory usage is there's really been a reversal in terms of handles and pointers on OS 9 the handle was really the first-class citizen it was designed to work with that limited application partition that heap and was designed to be reused inside that limited space on 10 the reverse is the case pointers are really the first-class citizens and there's some cost to handles so in performance critical code look at rewriting to use pointers instead of handles we found one case where just removal of h lock and h unlock in this code path made a big difference in terms of performance the reason there was that the the locking costs are sufficiently higher on 10 than they are on 9 and what work had to be done was really impacted by that and this is something that you should do kind of carefully the OS itself I mean if you're looking into this kind of an optimization the OS itself doesn't this doesn't rely or doesn't go and purge and move handles out from under you that's really under your control intent and so if you know that you're not resizing the handles somewhere else in your code if you know that you're not looking at the handle to see if it's locked then you're likely able to make this kind of an optimization then lastly I hope it's pretty obvious is that there's really no purging the calls are still there they're largely there so you can run the same app on both 9 and 10 but your purged crocs are not going to get called the application heap is not going to fill up and if you're relying on basically allocating allocating allocating until you get called in your purged proc that's not going to happen that's the biggest leak you can ever have so take a look at that if you're you're in that kind of a category okay code loading this is something that kind of referred to earlier on and launching a bit in that I said something to the effect of defer some of the things that you do at launch time to later on and one of the ways in which you can do this is to factor your app most application code bases start off and are organized basically you know by the people that work on them first so you get you know you get Kelley's feature and Mary's feature and John's feature and they go off and do those different pieces of it and then neaten comes along and he has a new feature to add and pretty soon you've got one little piece of the app whether it's a shared library or a plug-in for each person that's working on it and soon those features grow up and there's a whole team around each of those features and before you know it the organization your app looks a little bit like the organization your organization right and that's rarely the best organization in terms of performance you really want to look at the features in terms of what the app really needs probably want to look at layering and dependencies so factoring in your app in terms of performance is something that I would advise you to do it's usually not something that you would do quickly it's something you probably converge on over time look at plug-ins for things that are truly optional again I don't mean this is a optional innocence no one would use it an example of this in the real live OS is nav services and printing those are both good categories from the OSS point of view of services that are purely optional in that the application your application can run fine do lots of good work and never interact with now services or printing so why should they pay the cost upfront the answer is it shouldn't so look for those kind of opportunities in your app maybe there's a plugin no you know has all the bells and whistles that you could ever want but you only use it once in a blue moon factored that out so you don't pay any costs for that don't give that app that plug-in a initial load and say are you happy with things that will cost then finally look at your libraries look at the number of libraries that you're using libraries when backed by files are costs that costs all the way down to kernels the kernel has a fixed cost there's a prosper process cost if your tools support it take libraries and combine them together merge your pep libraries together into one big file that's in fluent better from the performance and resource use point of view okay in the async i/o space we've seen some problems that are kind of interesting and combination of async i/o and threading asynchronous i/o on ten by that I mean deferred tasks file manager time manager those are all implemented based on running the operation in question synchronously on a thread that the OS creates for you and particularly when used with cooperative threads or working use combined there's additional costs there in general this is not performing as well as the equivalent on nine this is a case where I would recommend do it continuing to do async i/o and chain completion routines on nine factoring your app and dynamically checking and doing something entirely different on tenth the simplest workaround or the simplest solution on ten is really just to use threading in a synchronous i/o model and then just a data point we ran with one of there was an app or two that we've seen that implement threaded packages threading packages on top of the time manager the time manager is itself implemented as a threat which means you're threading on top of a thread that's scheduled by the kernel which is you're trying to run threads on top of something that's already being managed by something else not a good performance solution in the context of cooperative threads there's one basic flaw with cooperative threads and that is that the norfolk whopper threats that gets scheduled you have to yield and there's no blocking going on so by their very nature cooperative threads are compute bound that's the biggest problem they're still there because we know you have code that depends on it I would really look at not using cooperative threads or potentially using timers Carbon event timers instead or moving your code off to MP threads often there's a performance problem with regards to messaging between threads this usually has to do with messaging as opposed to or polling to see if some message base thing is complete versus true messaging and there I would just encourage if you're doing things with multiple threads even across processes make sure that you're not getting in this situation where both of the threads are competing the casing in the data point that I have was basically one thread was doing a lot of file i/o and was reading and writing to a file and the first thread was basically looking to see if it was done and the cleaner solution to that and a better performing solution is basically have the the second thread just block and when the file i/o thread is completed just send it a Carbon event to get that whole thing to work well and then finally seen situations where basically people just go thread happy they have just way too many threads for no real apparent reason and just bear in mind that each one of those threads has a real cost there's a in a wired memory cost in the kernel and they're not free so use them diligent and then finally threading in general can be used to really help out with performance I would say look particularly look for things like when you're trying to do a safe save or a fast save kind of feature that's a very good use of a thread you can create the thread do that you work on it and dispose it a network listener is another model that works really well out where the thread is just basically listening for incoming activity and occasionally there's a good use for threading when you're doing low priority idle kinds of computation maybe you're indexing something in the background something like that okay so finally at the summary really want to encourage you to factor performance into your planning try to really make it be a feature of your application we want that killer app to be that much better by performing well performance isn't a one-shot deal you really have to keep it in your your workflow you got to keep on on keep on top of it ideally you would you know we've built different builds of your app try to capture data about that about how it performs and see and pinpoint where performance problems were introduced and then I really encourage you to get into the tools the tools talk is later on this afternoon and all those tools are on the system you should just become experts at those tools allow you to look at your app in various different ways and they've really helpful in pinpointing these problems and lastly just go after those performance problems all right so now let's see oh yeah one last thing so the first one the carbon developer documentation you should just generally know the second one if you're not ready to do anything with performance at all you're stuck behind a whole bunch of a couple months worth of features on your app you're still carbonizing anything like that at the very least remember the second URL up here that performance PDF file has a lot of information on performance a lot of what I've gone over and what we'll be going over in other sessions is in that one document okay I'd like to bring mark up and then we can help do the roadmap and then we'll head off to Q&A thank you John there we go that won't work okay so as John mentioned we'd like you all to attend the performance tool session at 5:00 today if you possibly can we're gonna talk about the various tools that he introduced you to and also because we don't have a lot of time right now to take questions I ask you to take your questions to that session and we'll have some of the same people there to answer them but we'll just take a couple right now so if we can bring up our Q&A panel we can do maybe two or three questions oh by the way this is me so if during or after the conference you have any questions or comments about carbon or carbon performance send them to me at this address you