Well, good morning and welcome.

I'm Bud Tribble, Vice President of Software Technology at Apple and I'm going to talk about maximizing battery life in OS X. Now, you know, battery life is just a key feature for customers. I know its key for me, I know its key for you. And as you can tell from our key note sessions, battery life is one of the places where we put a lot of focus in OS X Mavericks. And the reason is simple, mobility is a key feature for our customers and battery life is key for mobility. Now, mobility has always been an important feature.

However, the user experience for mobility is not always been great. This is actually an Osborne 1, you probably don't-- most of you probably don't remember but the Osborne 1 was famous for being the first computer you could carry around with you. However, even that in that case because of the CRT and other things, you had to find a place to plug it in as soon as you wanted to use it.

Of course things have gotten a lot better over the years but nonetheless if you are at 3 hours battery life on your system, you're spending most of your time just wondering around looking for the next plug and I'm sure you've all been in the airport and that sort of a situation.

Now, your battery life will vary depending on what you're doing of course. But the goal that we set out for was that for most of the people, most of the users, most of the time their battery would last all day, they would plug it in at night and that was it.

Now, we know that that's a game changer because of our experience with products like iPad, where that's the usual behavior and once you get to that sort of threshold, life gets a lot better, there's a lot of bang for the buck in getting to that point. Now, our latest products which I'll go into some more detail we think we've gotten there through a number of techniques.

It wasn't easy but it was a lot of fun over the development really with a laser focus on battery life, kind of a new perspective in how you develop apps. I hope to sort of translate some of that to you or to-- I imbibe you with that because in fact application developers have a huge impact on the user's battery life as well.

So, here we have a typical customer out at the beach, they've got the-- I don't know if this is Mavericks, probably isn't Mavericks but here's a surfer who is, you know, in between surfing is editing his movies with Final Cut Pro. Well, even in this case assuming he spends a reasonably long time surfing even with a heavy duty app like Final Cut Pro he may experience all-day battery life. Users do not use our computers-- do not use their computers continuously and you can give them that experience of only plugging in at night in just a wide variety of situations.

Now, with the latest MacBook Airs combination of the hardware and the latest MacBook Airs that has well ULT processors which are very efficient, and Mac OS X Mavericks we think we have reached that threshold where people can start to not think about their battery during the day and we think there's incredible value to that. Now, I'll go into some detail on how we get there, it's actually there's a lot of ingredients that go into giving the customers a great battery life.

Starting with chemistry, the chemistry in the battery, now we're used to Moore's law with silicon wherever 18 months things get twice as-- you have twice as much compute power, that's not the case with chemistry. With batteries, batteries have been slowly but surely getting better over the year but the gains are measured in single digit percentage points.

Nonetheless, Apple's been paying a tremendous amount of attention to battery life technology and battery chemistry and we have gotten gradually better. So, this is one of the ingredients in getting there in terms of all-day battery life. Second area though, the hardware itself the silicon, both at the atomic scale, the nanoscale and the architecture of the chip itself, that's extremely important at getting to all-day battery life. I'll go into that in some detail.

Of course the system software is responsible for scheduling the CPU and other resources in the way that's most energy efficient and we've done a lot, this is where we've done a lot of work in Mac OS X Mavericks to make sure that things are as efficiently scheduled as possible that the energy is being spent on work that the user actually wants done versus work that maybe they don't care about. So, we'll go into a lot more detail on that and actually a lot of sessions further on during the week we're going to focus on that sort of thing as well. And then finally, as I mentioned you the application developer are part of the equation here.

And it's important for you to use the tools that are provided in Mac OS X Mavericks to take, take a microscope, take a closer look at how your application is using energy and try and maximize the efficiency to give that customer that all-day battery life that they really want.

Now, Apple is, as a company, uniquely positioned compared to a lot of others being at the intersection of hardware and software. We build hardware and we build the software that goes with it. The system software so we can spend a lot of time making sure that those two things are optimized together and play well together to give maximum battery life possible.

And that's what I want to spend some time talking about. How the hardware plus the software working together maximizes battery life. Now, silicon itself has come along way in the last thirty years. So, this is actually on your left. The original 68K, the 68,000 processors that went into the Mac 128K and Mac 512 back in 1984. Now, that chip had oddly enough, around 68,000 transistors on it.

The Intel Core i7, the fourth-generation Core i7 that we have in the MacBook Air has about 1.4 billion transistors on it. Now, you know, the transistors in the original Mac we're not all that efficient. In fact, if they drew the same, if the transistors in the Core i7 were drawing the same amount of power as the transistors in the 68K, then the amount of power needed to run the Core i7 would be equivalent to the power drawn by about 10 US average households about 20,000 kilowatt or 20,000-- 20 kilowatts.

Obviously, you know, a lot has gone into making sure that that catastrophe doesn't happen, one of the things is of course the transistors just got smaller but again, this chip is running at a higher frequency and thus using more power just because of that. So, a lot of work had to go in to the physics of the transistors in order to make them more efficient. I want to talk a little bit about some of those.

So, Intel in starting at the early 2000 began using something called strained silicon, not just normal silicon but strained silicon. Strained silicon actually has germanium atoms inserted in between the silicon atoms and the net result of that is that-- is that they can run at a lower voltage.

The voltage gap is lower and running at a lower voltage has a big effect. Energy draw tends to be proportional to voltage squared so anything you can do to reduce the voltage and still switch those transistors has a big effect. So, Intel put a lot of effort into moving to strained silicon.

But that wasn't enough. These things went forward. Another problem arose which was that between the gate and the channel in this transistors, there's an insulator, silicon dioxide. Well that silicon dioxide as the transistor shrunk was getting to be just a few atoms thick. And as a result electrons actually tunnel through there, they're leaking through there and that leakage is simply wasted energy.

There's R-squared energy leaked, being wasted in that case. So, what Intel did is they looked around and they said, "Is there any way we can make those gates a little thicker but still get the same capacity." And that's where they came up with what's called high-k metal gates.

And that those start being used in 2007. That was a big breakthrough because you could get rid of that leakage that would-- was really sitting there continually drawing down your battery and they used a material called hafnium, hafnium oxide which oxides which have a very high dielectric constant so you can increase the thickness of the gate.

And then finally, most recently in 2011, they came up with something that I guess they're marketing guys called it Tri-gate but it's really a three-dimensional structure for the gate so that the gate can actually be on all three sides of the channel of the transistor rather than just a plate on the top of the transistor. And these transistors are much more efficient maybe 50 percent more efficient. So, there's going to be more things in the future but you can tell even-- even at the nanoscale, a lot of stuff is being done to make these chips more efficient.

Now, what's the result? The result is that on the latest chips, we're talking nanojoules or tens of nanojouels per instruction. So, what's a nanojoule? So, a nanojoules is a billionth of a joule and a joule, a billionth of a joule is a very tiny amount of power. I like to think sometimes in terms of biology and in fact when a neuron fires in your brain its taking on the order of picojoules, about a thousand times as much. So, you can sort of think of an instruction executing in the Core i7 as being same amount of power, same amount of energy is about several thousand neurons in your brain firing, so your brain executing one instruction.

So, we're really getting down there to the level where biological systems have evolved over obviously billions and billions of years. Now, this is a micrograph of the Haswell ULT chip from Intel and, you know, it's a small chip about the size of a fingernail but on here are 1.4 billion transistors. And that's divided up into the functional units the-- in this chip there are two cores.

There is a huge amount as Phil said yesterday devoted to the GPU to the graphics processor. There's the shared L2 cache, the memory manager and some of the things for managing DMA. Now, the interesting thing about modern chips is that during execution, you can power down parts of those chips that aren't being used.

If you're not using the GPU right now, you can turn off that part of the chip, saving energy. If you're not using both cores, you can turn off one of the cores. You're not using both cores, turn those off. And that turns out to be architecturally one of the key ways to save power in these portable systems that we have today.

Now, it requires close interaction between a system software and the silicon in order to make that happen correctly but as we'll get into, if you do it right, you can save a huge amount of power. Now, this shows you what that looks like and in reality, this is actually, it's not Haswell, it's Ivy Bridge previous generation but it's what called an infrared emission microscopy. So, you're looking actually at the heat waves coming off the chip as its executing.

So, the blue spots are cooler, the orange and the red spots are hotter and in this case what you have is one core is powered up, this is a four core system, so you see one core powered up, the shared L3 cache is powered up. The GPU down at the bottom is powered down.

And here's some other examples of states that that chip can be in. The middle one shows all four cores and some and the GPU going at a fairly fast clip. The last one shows all four cores, all the cores are powered down, the GPU is powered down. It turns out that just a normal course of using a computer interactively, the chip, the CPU chip spends most of its time typically in that state.

That's because, the CPU is often waiting for user input. It's waiting for the network I/O to interrupt. It's waiting for the GPU to be done. A lot of the time in modern chip is spent with parts of that chip or even most of that chip turned off. So, what do you get from that? That you get a tremendous dynamic range and how much power that should CPU chip can draw. When it's idle, when it's not doing much and parts of it are turned off or powered down, you can get down to 0.4 watts.

On the other hand if you're doing a while one loop and the thing is just sitting there spinning or a CPU limited operation transcoding a movie or something like that, that can boom up to 25 watts, 30 times more power. And if the thermal conditions are right, you can even kick in to turbo and get up to maybe 60 times more power than an idle chip.

To let you know how this compares with total system power, remember that was just the CPU, well when you're idle, the CPU is a very small part of your system power because a lot of power is going to the backlight. It maybe go into Wi-Fi, radios and other things and the power supply. And so, the CPU at idle when it's mostly turned off is a very tiny part of the total system power.

However, when you're doing CPU limited operations, you've got a tremendous amount-- the lion share the power going to the CPU and that overshadows things like the backlight. That's important thing to keep in mind. That tremendous dynamic range means that the software and apps you write have a tremendous impact-- tremendous leverage on how much power is being drawn and thus how much-- long the battery is going to last.

Now, with interactive systems, most of the time as I mentioned, the CPU is actually powered down or clock gated or not drawing a lot of power. It is a more or less idle state. The reason is that user events don't occur very frequently compared to the time scales of executing and instruction. So, even if you're typing 50 words per minute which probably most of you can do-- that's one key every-- more quarter of a second more or less.

That's a huge amount of time in between responding to those events that potentially the CPU can be [inaudible] assuming there's no network activity, et cetera, et cetera. So, that's a key strategy to take advantage of the fact that on interactive systems, you're really spending a lot of your time with the CPU idle. And to show you what that looks like, this is actually a trace of CPU activity. So, system wide CPU activity as someone is in Safari, they're browsing to apple.com.

So, at the beginning here you have their typing and as I mentioned, you've got less than 10 percent of CPU activity. That means the CPU is essentially shut off 90 percent of the time. And then you go to where you're fetching doing HTTP gets from the network and the network is not infinitely responsive, so you even have time in between those network, in between those gets to put the CPU to a low power state.

Then finally when you're rendering, the CPU is waiting on the GPU to render those pages. So, again, less than 5 percent activity. So, if you were to-- if you're able to look at CPU on, CPU off over the course of time. So, this is about five seconds. You see that there are many, many rapid transitions from the CPU being powered up fully running to the CPU essentially going to sleep in between events, in between network packets, in between GPU invocations.

So, the key here is to make sure that the percentage of time spent in those low power states is the most that can be. Now, if we zoom in here, this is a 1 millisecond time scale. We see that there are pretty huge gaps where you could literally execute tens of thousands or hundreds of thousands of instructions but instead you're-- the system is putting the CPU into a low power state. Well, it would be nice if it was just like turning a light switch on or off to put it on those states but it's not. It's not that simple.

In order to get the CPU to turn off or to turn back on, it's actually a fairly complex process. So, in this case, it takes time. This is not actually turning the CPU or the core completely off. This is an example of what's called clock gating-- you stop all the clocks going to that part of the chip. And in this case, you stop the phase-lock loop that is supplying the clocks for that part of the chip.

But, that means that when you want to turn it back on, you have to start up that phase-lock loop. You have to get it to sync up with the rest of the chip and then finally, you get to turn-- start doing useful processing after 10 to 15 microseconds. So, there's overhead associated with turning the chip on or off. It can be even more than that. In this case, you're taking the voltage to the core and you're dropping it all the way to zero in which case you lose all state.

That means that when you turn it back on, you're spending time reloading state for that part of the chip could be hundreds of microseconds. So, in these cases, what's happening is that you're applying full power to the chip in order to get it up, turn on again, but you're not doing any useful computing power. That's wasted energy for that time.

And, that adds up over time. So, here's going back to our diagram of CPU turns on for a bit, turns off for a bit. But, those RAMs are intended to show that during that time, you're powering the chip, you're not doing any useful work, that's wasted power. So, the strategy here is to minimize those times.

Now, how do you do that? Well, that's where the system scheduler comes in. That's where how timers are scheduled comes in. And, that's what we'll spend some time talking about. But the basic idea is simple. The basic idea is if you can shift around that work and batch it up into a single packet of CPU work then you can turn on the chip once, do your work, turn off the chip and those red areas which are essentially wasted energy can be decreased into just a couple of them. So, this is what it looks like when you do that.

So, scheduling that work in bundles or in batching it up together is one of the key strategies that's used by Mac OS X. And we'll spend a little bit of time talking about how that interacts with App Nap, how perhaps that interacts with the application you're writing, how you can do that in a way that lets the system coalesce these things and decrease that red rectangle the time it takes to power the chip on and power the chip off.

So, to review, in an interactive system its idle most of the time-- it's idle much of the time. And modern chips can take advantage of that by turning themselves off or turning parts of themselves off when they're not needed and the key strategy is to batch work together so that you're not spending a lot your time ramping up and ramping down. So, maximize idle time, minimize transitions.

So, let's talk about how OS X Mavericks addresses these sorts of issues. And I'm going to talk about several things. One is sort of on the tool side, making energy impact visible. And if you want to improve any aspect of the system making it so you can measure that is key and we don't exactly have ammeters that we can go in there and put on apps or put on processes but we have corallites of energy use and we'll talk about how we used those.

Second thing is system strategies and application strategies for energy efficiency and that gets to some of the things I was just talking about. How do you batch up work so that you're minimizing the amount of those wasting energy wasting transitions that are going on. And finally, what you can you do as developers? I mean there's a lot we can do as a system developers down at the low level but actually, this bubbles all the way to the apps and how the apps behave and how you can change your apps to be more power efficient.

So, starting off in our-- in OS X Mavericks, if you go up and you look at the battery status menu, you'll see some new things in it. So, in this case, we are actually showing applications which are using significant energy. Now, in many cases, that will be entirely expected and desired if you're doing a render in Final Cut Pro, it's going to show up there. If you're doing a batch compile in Xcode, it's going to show up there.

On the other hand, you may have something show up there that is unexpected and maybe undesired and we're going to make that visible in the battery status menu. If you double click on any of those, it will take you to activity monitor and in activity monitor we have a new tray or a new tab which is the energy tab.

The energy tab shows two new columns. One is called energy impact. I'll just take a moment to say what that means. So, energy impact is a surrogate for trying to look at the energy impact that an application or a process is having. Now, as I mentioned, we can't stick a power meter on it directly but what we can do is look at the CPU usage by that app and look at the interrupts or timers that are caused by that app and cause the CPU to wake up. In other words, cause one of those red rectangles that I was looking at earlier. And we track those using counters and we apply that to the energy impact that that app is causing.

So, you get a number that is a relative measure of energy impact by an app or by a process. And further than that in the next column over-- so that's the column with the energy impact. Next column over, we show the average energy impact over the previous eight hours.

So, actually the previous eight hours or until, you know, back into the last time you booted your system if that was less than eight hours. But this is important because, number one, you might have something-- an app that had come in there run for five minutes and burned a lot of your battery, and now it's just quiescent but you'd like to know that that happened at some point and that will show up in that eight hour average.

Just as important, you may have the apps that are just using battery energy at a low clip but they're constant, they're just going on all the time. Again, the history, the average makes that visible. So, this is the first clue that there might be something going on you don't expect or that the user doesn't expect.

Now, as a developer what you're going to want to do then is go into Xcode. And in Xcode, we have quite a few more tools that let you take the next step to investigate why this app might be using energy. So, in the latest Xcode, we have what's called the Energy Gauge, Energy Impact Gauge.

Go to the-- if you just run your app, that'll show up on the left there. You can click on that and it gives you much more insight into, is your app firing off timers? Is your app using CPU? Why might it be doing this? Can I go look at the event timeline and see-- you know, make sure you understand why it's doing that. As I mentioned before, it maybe doing very useful work but it maybe doing work that you can do in a more efficient way.

Now, we have built in to OS X Mavericks, strategies that we use across the board to make things more efficient from an energy standpoint and I want to talk about three of those. First one is App Nap. An App Nap was mentioned yesterday. I'll go into little bit more detail into what App Nap is actually doing and there's going to be further sessions coming up that will go into great detail and APIs around that that I would suggest you go to.

Centralized Task Scheduling is the next one. Centralized task scheduling is a much longer time scale but it's about moving work around to times they're more opportune, either more opportune from an energy standpoint, you're back on AC power or more opportune just from staying out of the way of the user.

And then finally Power Saver, and this all about Safari and providing a web-browsing experience that is power efficient. So, let's go through those. First of all, App Nap. So, a typical use, you know, users interacting with one application on the screen but of course they've got, you know, many other apps up in the background.

Now, the app they're interacting with is where they're really interested in results. But the apps that are in the background when you measure systems often are sitting there drawing power. They maybe drawing low levels of power, they maybe drawing medium levels of power but they're drawing power and often times they're not doing things that the user is really-- all that interested in at that moment.

So, what App Nap is all about is quiescing those apps that the user is not interacting with or that are not visibly drawing on the screen or they're not creating an audio output stream that they're going to hear. So, we use heuristics to decide when an app is a candidate for App Nap. Once we decide it's a candidate for App Nap we start doing a variety of things to suppress the energy use by that app.

And, you know, devote, thus devoting most of the energy to what the user is interacting with and what they're interested in. So, what do we do? Well, we will adjust CPU and I/O prioritization. But beyond that, we will also be more aggressive about coalescing timers in that app or in processes associated with that app.

So if there are timers that are being set we will move those timers around to align them with other timers so that you don't have this overhead of power-- potential overhead if the chip is coming out of a low power state and going back in. You don't have that potential overhead occurring over and over, you coalesce those into one. Timer rate limiting which is a little bit different which is for repetitive timers, we stretch those timers out. And finally, there's some APIs.

We are able to tell an app when it's visible so it potentially take action to decrease its energy usage. And we let the app hint to the system or pass information to the system about how it expects to use resources so we can do the right thing in App Nap.

So, Timer Coalescing. As I mentioned before, the key is batching together work so you don't have-- you're not paying the overhead of these transitions. So, here in the red rectangle or the overhead of the transitions for the CPU coming to a high-power state, from a low-power state or vice versa and what we're going to do is-- if the app is being App Nap, be more aggressive about squishing two of these events together we're going to slide those timer firings around so that you only get a single transition.

And overtime, these add up it's-- we keep the timers in exactly the same order that they were set but we change the exact time in which they fire, we slide them around to coalesce them. Now, there's also an API for NSTimer and DispatcherTimers that lets you tell the system how much leeway or how much tolerance you can accept, let's say 10 percent, you'll accept the 10 percent sliding of that timer and you've made the judgment that's not going to really affect how things come up.

Now, there are timers and apps where that has to be as close as possible. And that really gets into the realm of real-time apps which we're not really talking about here and there are things like audio playback where you need exact timings and will opt those out of App Nap.

But, for timers associated with perhaps network polling or perhaps user interface related interactions, those kinds of timers typically don't have to be accurate to the nanosecond. And, if you tell us we can slide those timers around. If you give us tolerance then the system will automatically merge those to get rid of the overhead between those.

So, here we have an example and what you've done is really reclaim that wasted energy due to those transitions that were there earlier and you've combined the work into a single batch set of work that gets done. Now, this is happening on the order of hundreds of microseconds or maybe milliseconds. It's something that-- if everything is operating correctly, the user doesn't even notice except that their battery life gets longer.

Timer rate limiting is a little bit different. If you have a repetitive timer in one of those background apps, one of those apps that is not drawing, that the user is not interacting with, perhaps you've got-- you left the timer going at a frame rate, 60 times a second. To update some variable that you want to keep up-to-date, well, we will rate limit those timers and essentially stretch them out.

So, we will let those timers execute but let them execute at a much lower duty cycle rate. That means that whenever processing is going on and associated with that timer is now occurring at a much lower duty cycle and the power associated with that or the energy associated with that is correspondingly lower.

So, those timers continue to fire but they continue to fire at a lower rate. And again, this is happening in apps that are not drawing to the screen, they are not outputting audio, these things are not noticeable to the user except that they have less draw on the battery, they're using less energy.

Now, we also have as I mentioned, an API that lets an app find out whether it is visible on the screen. And, here's an example of where we use that to conserve energy. This is Photo Booth, Photo Booth is-- comes up in preview mode, it turns on the camera, it's displaying the preview on the screen there. If Photo Booth gets covered up by another app, there's now an API to find out, "Hey, I'm Photo Booth but I'm not showing on the screen." And, Photo Booth will now use that API to find that out, turn off its camera thus saving power.

In the case where you got repetitive timers going on, even though App Nap will stretch those out for you will-- will rate limit those for you. And even better situation in that case is to use the API to tell you, "Hey, your screen is not-- your app is not visible on the screen at all." And if appropriate, turn that timer off completely.

So, you know, the combination of the system activities plus APIs that you can use really helps the system as a whole, give the user the maximum battery life. You find out more about this in a couple of sessions coming up improving power efficiency with App Nap which we'll go into great detail about App Nap and APIs associated with App Nap and exactly how it figures out when to nap something.

And Energy Best Practices which is a lower level talk that covers a lot of these concepts but others as well. Both those talks I think are very worth going to-- the second one, will have a lot of tools in it that you can use and cover how you will-- how you can maximize energy efficiency for your costumers. Now, Centralized Task Scheduling.

Centralized Task Scheduling as I mentioned is on a much longer time scale and it's a dual use technology. It can be used to move tasks to a time that is better from a battery life standpoint say back on AC power. So, you might have a task that's going to run-- use up some of your battery, but it's a task that can wait hours perhaps before it runs. It's a housekeeping task and we have a system-wide facility for rescheduling that to be executing when you're back on AC power.

Also, tasks that are may be going to use significant CPU that you really only want to run when the user hasn't interacted with their system for awhile. In other words, the users probably gone to get a cup of coffee, now is the time for an intensive, you know, background task to execute. So, Centralized Task Scheduling is a general mechanism for doing that.

And you can tell the system how you can-- first of all tell us "Is this some work that can be time shifted? Can it be time shifted to either back on AC or time shifted to when the user is not interacting and by how long? What's the maximum amount you're going to let the system time shift it by?" Maybe it's a software update. You don't want it to go more than 24 hours.

Maybe it's a backup you don't want it to go more than a few hours. Whatever that is, you tell the system through this API. And there's a two APIs for doing that, one is if you're task is a LaunchD Task. You simply put that in the launchd.plist. There's a way to specify-- can this be time shifted and by how long or directly in your application.

There's an API, if you've got let's say a block that you want to execute on some schedule, you can tell the system "Hey, this block can be delayed by up to 8 hours." And that takes some work on your part but it provides a much better experience for the user both from a battery life standpoint and not doing tasks that sort of get in their way when they're being very interactive.

So, Centralized Task Scheduling. Couple of sessions coming up on that. This will be covered in Energy Best Practices which I mentioned before and also Efficient Design with XPC. So, XPC is one example where you have a block of code. It's going to execute but can just as easily be put off until later. The system will make a decision based on battery efficient or battery life to move out to back on AC power.

Finally, Power Saver. So, Power Saver is all about Safari and it's really some of the same ideas, same strategies we just talked about with App Nap but applied to the web browsing experience. So, for example, in Safari, as the user is browsing, typically they've got tabs-- they've got a tab they're looking at, they've got other tabs that are in the background but if you look at what happens on those web pages often times those tabs are executing JavaScript.

They're executing plug-ins. They're burning power. They're gradually dragging your battery down. So, what do we do? Well, since in Safari, we now have a separate process per tab. We can use those same techniques we talked about in App Nap to quiesce those tabs if the user is not paying attention to the ones that are in the background. That actually has a significant effect given the web pages that are out there today often-- they are just sitting there in the background running their plug-in, running JavaScript and Safari will take care of that with App Nap.

In addition, in web pages today, often times, power is being drawn by plug-ins. Plug-ins tend to be power hungry and so these plug-ins are-- they're useful but Safari is smart about how it handles plug-ins with respect to energy, the latest Safari in Mavericks. And what it does is for plug-ins that are not the center of your browsing attention-- marginal plug-ins, it will take a preview snapshot of that plug-in, display that until the user interacts with it, until the user clicks on it and then that plug-in will start executing. Great feature.

You end up with a web page that has these previews in it but they're not burning any power. They're not sitting there executing until the user goes and clicks on one. Now, if there is-- Safari uses heuristics, if there is a plug-in that's front and center then that one will play without interruptions. But if there's marginal plug-ins that are not the center of the user's browsing activity, those will still show up but they will not play until the user clicks on them.

To find out more about this and more importantly, if you're a web developer, you should go to the session on Power and Performance in Optimizing Websites because the Safari team is going to talk about not just this but also what you should do as a web developer to make sure that your web pages that you're sending out to users are not burning through their battery. That they're executing as efficiently as possible that the CSS is efficient, that the users battery experience is not impacted by a bad web page.

So, we covered App Nap, Centralized Task Scheduling, Energy Saver, three great features in OS X Mavericks that are going to help the users have a great battery life experience. So, what can you do as developers? Well, perhaps goes without saying but of course major effect on battery life is whether you're using efficient algorithms.

And, so just make sure that, you know, if you got tasks going on that should be they're nsquared algorithms that you're using and they really should be in login or order in, make sure that the algorithms were efficient. That's going to help everything. That's going to help responsiveness. That's going to help performance. That's going to help-- help you get the best battery life.

But beyond that, take a look, use the tools in OS X Maverick to take a closer look at energy impact of your application. Watch for your app in energy in activity monitor. Look at what it's doing, understand what it's doing. Like I say, it may be perfectly expected behavior. After all, the apps are supposed to compute and so they're going to use energy doing that.

But make sure that it's as expected and that it's not doing work that either the user didn't expect or worse that the user really didn't want. Then the next step is measuring your application with Xcode. And as I mentioned, Xcode has a lot of new tools in it to dive down more deeply take a look at things like time or firings the frequency of firings, do I have high-frequency timers that could have some tolerance introduce and let the system do a better job coalescing those, et cetera, et cetera. And then finally, adopt Centralized Task Scheduling.

Let the system move those background task things like, you know, downloading updates from the web, can be maybe pushed off for hours or even days. Let the system know about that so the system can make the right decision and put those events so they occur when you're on back on AC power or when the users are not interacting with their system.

So, additional related sessions that I would really recommend, Building Efficient OS X apps and this is efficiency not just from energy although energy is the one focused on but also from the standpoint of memory use, from the standpoint of just simply using the resources to their greatest effect. Efficient Design with XPC, I mentioned before and that's an area where you again can take advantage of Centralized Task Scheduling. Power and Performance: Optimizing your Website for Greatest Battery Life in Response Scrolling. That's going to be the longest title of all the talks here.

But anyways, if you're a web developer, absolutely go to that so that you can produce web pages that are more in energy friendly for your users. Improving Power Efficiency with App Nap, again a more deep dive on the mechanisms in App Nap and how those work and how your app can interact with those. And then finally, Energy Best Practices which is really across the board kind of more low level-- how OS X Mavericks focuses on energy.

So, to leave you, you know, it's really important I think to understand that battery life often for users becomes almost the most important feature to them. More and more you see people out on the road. They're using their systems in a mobile fashion. They're used to all-day battery life from their iPads.

So, this is the new norm and we need to get used to it and we spent a lot of time in Mavericks just squeezing every last ounce out of that battery and we hope that you can use the tools and the mechanisms in Mavericks, do the same thing for your apps. Thank you very much. [Applause]