Battery life is very important to your users. And apps are directly tied to battery life. So as developers, it's very important that we're careful about how we write our code. And the reason for this is if I'm a user and I'm having bad battery life, the first thing I'm going to do is I'm going to go to the Battery Usage screen.

I'm going to take a look at what apps are using a lot of my energy. If I notice that your app is near the top and I don't expect it to be there, I'm not going to be very happy about that and I may even delete your app.

And so today, I'm going to talk about some battery life concepts. Then, we're going to move on and we're going to talk about energy efficient coding practices. From there, my colleague will come up and talk to you about energy debugging tools that are available to you as well as give you a demo. And then we'll wrap it up with some final thoughts. So let's get started. What is energy? Well, energy is the product of power and time. And I'd like to illustrate this with an example.

As you can see here, when the device is idle, the power is very low. Yet when the device is active, the power is very high. And you also notice that the power can be even higher and that depends on how much work you're doing or the type of work that you're doing.

You'll also notice that there's overhead and that's the amount of power that's needed to bring the hardware up to be able to do your work as well as put it back to sleep. And so as I said before, energy is the product of power and time and that's the area under the curve. And I'd like to take this one step further.

The energy that you have is split into two regions: fixed costs and dynamic costs. The dynamic costs are the work that you're doing and the fixed costs are that overhead that we talked about earlier, the amount of energy needed to bring the hardware up to do your work in the first place. So even if you're doing a small amount of work, you're still going to have to pay those overhead costs. And we'll talk more about this later.

So our devices are very powerful and so it's important that as developers we're very careful about when we use that power. We need to really think about, do we need to use this power to deliver a great experience to our users. And if we do, we should go ahead and use that power. But maybe there're other times where we can conserve it.

So now you might be thinking, what consumes energy. Well, actually nearly everything in our devices consume energy but today I really want to focus on four main things. And these are processing, networking, location, and finally graphics. These are the four main things I really want you to think about when you're writing your apps.

So how can I reduce my energy consumption? First, I want to identify the work that I need to do, really think about will this work, help your user. And if it won't, don't do it at all or maybe defer it to a later time. Next, you'll want to optimize your work. Once you've identified the work that you do need to do, try to do it as quickly and efficiently as possible. Next, you'll want to coalesce, try to batch up your transactions. Don't do them spaced apart. And finally, reduce the frequency of your work.

So let's see how we can apply these principles to your apps. And first I want to start with networking. So if you're developing an app that uses networking or you have an app that does networking, you'll really want to pay attention here. And so I'd like to start with an example. I've been working on a social networking app and this app has three parts: a main feed, it has the ability to post a photo, and finally the ability to send some analytics data.

And so let's start with the main feed. In my current implementation, I'm just reloading on a fixed timer over and over again. And let's take a look at the energy impact in doing so. Here you can see that at first glance doesn't look to be that energy intensive; however, as we talked about earlier, they're actually those overhead costs and that's the cost to bring up the radio and put it back to sleep in this case.

And so even though you're just doing a small amount of work, you're paying those overhead costs and this is really resulting in a big energy impact. So how can we optimize this? First, we'll want to reload only on user interaction or maybe a notification such as an urgent news alert.

Next, you'll want to use NSURL Session Default Session and there's a new property called Waits for Connectivity. This will allow you the ability to know when you can connect to the server of your choice. Additionally, you'll want to use NSURL Session Cache as well. This will allow you to not re-download the same pieces of your main feed over and over again and incur those extra costs.

So, let's take a look at the energy impact with these optimizations. As you can see here, we've removed that recurring spike. Now you're only reloading on user interaction and notification. And you also removed that overhead cost as well. This is great for battery life. So let's see how we can set this up. First, we'll want to go ahead and create a default session configuration. Then, we'll move on and we'll set the waits connectivity property to true.

And finally, we'll configure our cache. So that was the main feed. Now let's move on and talk about how we can post a photo. So in my current implementation, right now I'm just going to send this photo immediately and I'm going to retry on every failure. That's because I really want to get this photo to my server. And let's take a look at the energy impact in doing so. As you can see here, the energy impact is very high. We're spending a lot of time to send up our photo. And finally it times-out, maybe because the networking conditions are poor.

And again, we retry because we really want to get this photo to our server. And again, we spend a lot of energy while we're not providing much utility for our user because this photo is still not getting to our server. And this may repeat over and over again.

So how can we optimize this? First, we'll want to make sure we really minimize our retries. Only retry maybe two or three times. Next, set reasonable timeouts, maybe 30 seconds or a minute. Don't spend too much time trying in case you're in those bad networking conditions. Finally, you'll want to batch your transactions, so if you have other photos to post at the same time, go ahead and post those as well. Finally, if your retry limit is hit, and you're not sure what to do, maybe create a background session. This will allow you to hand off your photo upload to the system and it can find a good time to do your work.

So let's take a look at the energy impact with these optimizations. As we can see here, now we've really reduced the amount of energy that we're spending both in the cost to send our photo as well as that overhead cost. Additionally, you might see that we're still timing out, maybe because those bad networking conditions are still there, but yet the second time we retry, we just go ahead and create a background session and now we're going to let the system handle uploading our photo.

So that was how we can post a photo efficiently. Now let's talk a little bit about how we can send up analytics data. And as developers, we all really care about how users are using our apps. So we want to make sure that the data that we're sending does not have an energy impact and we can do that by using Background Session. This provides the ability to hand off your upload or download to the system to do it at a good time. Additionally, it provides automatic retries so you don't have to worry about handling that retry policy yourself.

Next, it also provides throughput monitoring which means that if your throughput is very low, for instance you're in those poor network conditions, your task will be stopped and retried at a later time when it thinks it will succeed. Finally, there's some new properties called start time and workload size.

This will help you indicate to the system the best time to do your work. And finally, you'll also want to set the discretionary property whenever you're doing work that's not immediately relevant to your user. This will allow the system to find the most energy efficient time to do your work as well.

So let's take a look at an example. Here, we can see that right now I'm not using Background Session. I'm just going ahead and sending my data as soon as I have it ready to send to my server. Additionally, there's some other networking that's occurring in the future.

And right now we're paying two overhead costs. So let's say that we use Background Session. Now we can see that Background Session has allowed these events to coalesce together and saved us that extra overhead by combining it with the other networking that was already going to happen at a future time. This will really help battery life for your users.

So let's take a look at how we can set this up. First, we'll want to go ahead and create our Background Session configuration. Then, we'll move on and we'll set the discretionary property to true. Next, we'll go ahead and we'll set some properties like start time and the expected workload size. And finally, we'll resume our task. So that was how we can send up our analytics data in an efficient way. Now I want to talk to you a little bit about watchOS.

So, networking on the watch can be very expensive and so it's important that you use background session for any work that you want to occur when the screen is off. You want to also use this for complication updates or background app refresh as well and that's because you'll be able to get runtime when the task completes so it can go off and doing your networking and let you know when it's done.

So, to recap. First, you want to identify the work that you're doing. This will help you ensure that you're not repeating transactions again and again. Next, you want to optimize your work by using Background Session wherever appropriate. Next, you want to coalesce your work. Really batch those transactions up to save that overhead.

And finally, reduce your work my minimizing retries and setting reasonable timeouts. So that was networking. Now I want to talk to you a little bit about location. And so as a developer, you have many APIs to choose from when it comes to location. But today I really want to focus on the energy impact of these APIs.

So to start off, let's talk about if I wanted to add the ability to add navigation to my app. To do this, I'll want to use continuous location updates and the reason for that is I'll need to know if the user deviates from my course. That way I can provide them new instructions for how to get to their destination.

But one thing you want to be cautioned of is that this does prevent the device from sleeping, so it will have a high energy impact on your users. So really, as soon as your user gets to their destination, you'll want to make sure you stop these location updates and make sure the device can sleep again.

So let's take a look at how we can do this. First, we'll create a location manager. Then, we'll move on and we'll set some properties. And the property I really want to focus on today is desired accuracy. Really think about the accuracy that you need and the reason for that is higher accuracy is higher power.

So really make sure that you do need that high accuracy if you go ahead and set it. And then next, you'll want to go ahead and start updating location. Once you're done, for instance as soon as the user gets to their destination, stop updating location, again so that you can let the device go back to sleep.

So that was continuous location. Now let's move on and talk about some other APIs that will allow your device to sleep more often. The first one is request Location and this allows the ability to get the user's current location, maybe if you want to update content based on their current location without having to worry about calling start location and stop location and managing calling both of those.

Next, there is region monitoring. Region monitoring provides you the ability to know, let's say, if you want to update content when the user arrives home. You don't have to track their location all the time. You can just create a region and when they cross that region, you'll be able to get some runtime to do your work.

Similarly is visit monitoring. Visit monitoring allows you to know when users go to frequently visited locations. You'll also get some runtime at that time as well without having to continuously track their location. You can set that up as follows. And finally there's significant location change. So significant location change can be used if you want to know when the user is moving a significant distance but you don't want to use continuous location because continuous location prevents the device from sleeping.

Significant location change doesn't prevent the device from sleeping. It can still sleep between those updates. And so you can really make a good optimization if you're able to move from continuous location to significant location change. One example is maybe you have a weather app. You need to know when the user moves significantly and update the weather at those times. And here is how you can set that up.

So to summarize, first you want to identify the accuracy level that you need. Really think about do I need that high accuracy. And if you don't, use something lower. Next, you'll want to optimize your work by using alternatives to continuous location wherever you can and wherever it makes sense.

Next, you'll want to reduce your work by stopping location updates as soon as you're done with them. Again, if you let those location updates keep coming, you might prevent the device from sleeping. And finally, you'll want to coalesce your work by deferring location updates. Maybe in the future you'll need that location, you'll really need it and maybe you don't need it right now. So that was location. Now I want to talk to you about graphics. And graphics can be very energy intensive.

So here are some good guidelines to follow. First, you'll want to minimize your screen updates, really ensure that these are providing needed changes for your user. Next, you'll want to review your blur usage. If you're placing blurs on top of updating elements, this is very expensive for battery life. So be very cautious of that.

So those are some general guidelines. Now let's talk specifically about the Mac. So if you're developing on the Mac, you'll want to be aware that some MacBooks have a discrete GPU and this discrete GPU is great at delivering awesome graphics and awesome performance for your users but it also has a high power cost over the integrated GPU. And so you'll really want to make sure that you're only using the discrete GPU when your animation performance really suffers over the integrated GPU, or if the functionality isn't provided there.

Additionally, if you're developing on the Mac, you might be using Metal or OpenGL. And if you're using Metal, you'll really want to be aware that by just calling Create System Default Device, you're going to trigger the Discrete GPU automatically. And so if you don't need the discrete GPU, instead you'll want to call Copy All Devices and pick that device with the low power attribute set. This will ensure that you can use the integrated GPU whenever possible.

For those of you that are developing using OpenGL, you'll want to make sure that your app is mux-aware by setting the Automatic Graphics Switching property either in your Info.plist or using the sample below. And the reason for this is if you don't need the discrete GPU, you don't want to be the one to keep it up and automatically you will keep it up unless you set this property.

So to summarize, first you'll want to identify the work that you need to do by looking at your burry usage. Make sure you're not placing those blurs over updating elements. Next, you'll want to optimize your work. If you're developing on the Mac, really ensure that you're only using the discrete GPU whenever you really need it to deliver that great performance. And finally, reduce your work by minimizing screen updates whenever possible.

So that was graphics. Now let's talk a little bit about processing. And again, processing can be very energy intensive as well. So here are some guidelines to follow. First, you'll want to identify the tasks that you need to do. Next, you'll want to do that work very quickly and efficiently once you've identified those tasks.

You'll also want to avoid timers whenever possible. Try to do your work based on user interaction rather than a fixed timer over and over again. But if you really do need to use those timers, try to set a pretty long leeway. That will let the system coalesce your timers with other work.

So that was some general guidelines for processing. Today I really want to focus on background processing. And background processing can be very expensive for your users and so it's important to think about what you're doing in the background. The main reason for this is the user is not looking at your app. In the foreground, they're looking at your app. So if you're using some energy there, they might not be as worried. But if you're using a lot of energy in the background, your users might not be happy about this.

And so here are some general guidelines. First, we'll want to finish our work as quickly as possible. First think, do I really need to do this work in the background. And if so, find the most efficient way to do it. Next, if you want to update your content, try to use the background app refresh API.

This will really help you find the best time to update your content. And finally, you'll want to make sure that you call the completion handler for whatever API that you're using. This will make sure that you allow the device to sleep as quickly as possible and you don't end up paying any fixed cost.

So new in iOS 11, there's a completion handler in the PushKit API. This will allow the device to go back to sleep very quickly after you handle your incoming push if you call this. And so you'll really want to make sure that you adopt this if you're using PushKit. And let's take a look at an example. Here, we can see I'm not calling the completion handler in this case when I receive my incoming push. I'm just doing some processing and then I'm letting the device just go to sleep after a fixed period of time.

But now let's take a look at the energy impact with the optimization. By calling the completion handler, we are allowing the device to sleep more quickly and not only have we saved that energy that we're using in the background but also that overhead cost as well. That will really help the battery life of your users if you're using PushKit.

So let's talk a little bit about background processing on the Watch. So new is the background navigation mode. This also has CPU limits like other background modes on the watch. Additionally, you'll want to really make sure that you minimize any networking that you're doing when in this background mode. Really think about, do I need to do this or will my user care about this networking update that I'm doing.

Maybe do it for things like traffic reroute or important traffic information. And finally, use background app refresh and complication updates to update your data. And when you're using these APIs, make sure that you use Background Session, as we talked about earlier, to get that data so you don't have to wait around for the data to come through.

So to summarize, first you'll want to identify the work that you're doing in the background. Really make sure it's providing useful content for your user. Next, you'll want to optimize your work by using Background App Refresh whenever you can. Next, reduce your work by limiting the transactions that you're doing in the background. And finally, using background Session whenever possible. So now my colleague is going to come up and talk to you about the energy tools available to you as well as give you a demo.

Thanks, Daniel. Good morning, everyone. I am Prajakta Karandikar. I'm an engineer in the power team. So you heard about all the best practices for writing energy efficient code. Now I'm going to talk about the various energy debugging tools that we have developed. We will see how you can use these tools to measure the energy efficiency or energy impact of your applications.

These tools will help you find the high-level problems within your application pertaining to energy or the major problem areas and will help you fix these problems. Finally, we will move on to a demo where I'll take some sample applications and debug them for energy issues using our new tools so that it establishes a debugging workflow for you to debug your own applications.

But first, let us see why it is important to measure your app's efficiency. Say you develop this awesome application with some great functionality but did not measure its energy impact. Turns out the energy impact of the application is pretty high even with usage for a very small period of time.

Naturally, battery usage UI is going to flag this application as one of the top energy drainers and any customer who is using your application is going to experience a significant battery drain even with small-usage periods. It could be possible that the customer deletes your application and that is definitely not something that you desired.

So as an app developer, it is really important that you measure your app's efficiency pertaining to energy or its energy impact. And to help you with this measurement, we have the new and improved Energy Gauges. These are included as a part of Xcode, which you all are familiar with.

Energy Gauges are designed to give you a high-level overview of the problems within your application pertaining to energy. They will tell you what are the energy-heavy areas within your app. They will also guide you to the right set of instruments to drill down deeper within these problem areas and fix these problems.

So where can you access Energy Gauges within Xcode? When you launch your application with Xcode, click on the Debug navigator. A series of performance gauges open to the left-hand side of the screen. These are for the basic metrics in the system like CPU, memory, network, and disk. In iOS and macOS, one of these gauges is for energy impact. When you click on this energy impact gauge, the energy report opens to the right-hand side of the screen. Let me walk you through the various parts of this report.

At the top left corner of the report, you will see a value which indicates the overall energy rating or the overall energy score for your application. Alongside it lies a meter which is three regions: the green, yellow, and the red region corresponding to low, high, and very high energy impact.

So the bad news for this particular report is that this application which is being debugged has a high average energy impact. The good news, however, is that as you make improvements or optimization to your application, this meter will help you know whether you're moving in the right direction, that is towards the green or the low energy impact zone, or are you moving to the wrong direction, which is the red or the very high energy impact zone.

So if you see that your application lies anywhere within the yellow or the high regions, you definitely want to take a look at the pie chart which is at the top right corner of the report. So this pie chart tells you what does the average component utilization for the primary components which consume energy on iOS as were described to you by Daniel.

Ask yourself, do you expect your application to be using this much CPU, GPU, networking, location. You can start by eliminating whatever you did not expect your application to be using. Those could be some leaks within your application which have left some hardware running indefinitely and which are resulting in a greater energy impact.

For example, say you have developed a gaming application which uses only the CPU and GPU and it requires very little location that is to access the location of the user when the user starts playing a game. But if you see from the energy report that the pie chart tells you that your location utilization is very high, that could be a possible leak within your application where you're continuously accessing location and that could be something which is resulting in excessive energy drain.

So once you have eliminated whatever you did not expect your application to be using, next you should try to optimize whatever stands out or is the biggest portion within the pie chart. So for this particular example, we see that the red region, which stands for overhead, is the biggest piece in the pie chart. We know that overhead is the energy that is required to bring up the radios and all the other system hardware which is required for your application to perform work.

And this seems about right considering that your application is also utilizing the networking component. Networking is going to bring up the radios which will require power for prolonged periods. So in this case you can try to optimize your networking utilization. Try to batch up all your networking activity within your application whenever possible so that it reduces the impact on the networking as well as the corresponding overhead which has resulted from it.

Once you know which is the primary component that you want to try to optimize or improve first within your application, you should look into the segmented bar chart or the instantaneous section of the report. This gets refreshed every second. This is great to find whether what your application is doing over time makes sense.

So when you execute certain actions or scenarios while you're trying to debug your application using energy gauges, you can see here what is the exact point of time when you consumed energy, which are the various components on which you generated a workload. This region also tells you whether that workload was generated while the application was running in the foreground, background, or suspended states. So here you can verify whether you're adhering to the good principles of doing as little work as possible or no work if possible in the background state and moving immediately into the suspected state whenever your app is backgrounded.

If you do an extended click on any one of these bar charts, it will give you a breakdown of the component utilization for that instant. So this section is great to find what are the opportunities within your application to reduce or to coalesce work. In this particular example, you see that you're repeatedly doing networking activity and that's why time and time again you have the networking impact as well as the overhead impact which is generating from it. So this is a great example that you can batch all your networking work and that is going to lower the energy impact for your application.

At the bottom of the report, you have information regarding the various components which consume energy on iOS and some useful tips regarding how you can reduce your application's impact on each one of these components. To the right of these tips, there are buttons to click into instruments. So say from the energy gauge's report, you saw the CPU utilization for your application is maximum and that is something that you want to try to optimize. So you can click on the Time Profiler instrument and this will move your debugging session into instruments time profiler.

So Time Profiler basically watches all the running threads of your process and it generates samples at regular intervals. You have a complete back-trace available for each of these samples and that can be seen on the right-hand side in the Extended View section. So this helps you find what are the exact lines of code within your application which are extremely time intensive, where was most time spent within your application, which functions within your application were extremely CPU intensive, and you can try to optimize that part of your code and rerun it for debugging using Energy Gauges.

Similarly, if Energy Gauges report told you that your location utilization is extremely high and that is something that you want to go and optimize, you can click on the Location Profiler. This tells you what are the points in code where you have made access to core location manager.

You can also see what was the accuracy that is demanded for each of these calls and what is the resulting energy impact from these calls. So in this particular case, we see that the location manager is being accessed time and time again with the best accuracy possible and, hence, there is a high energy impact that is resulting from each of these location calls.

This is also a great place to find out whether you have left any leaks in the system. That is whether all calls to locations manager have been successfully released. You can also try to incorporate the good practice of using lower accuracy whenever possible within your application so that it lowers the energy impact resulting from it.

Now that we have familiarized our self with the various tools that are available for energy debugging, let us look at some of the scenarios that you should execute on your applications while debugging them for energy issues. So there are some scenarios that could apply to every application. For example, there is the launch and idle scenario, whether the user launches your application but does not interact with it. Secondly, there is a backgrounding scenario. So you should try to run these scenarios using Energy Gauges and see what is the resulting energy impact that is generated from performing these actions on your application.

Next, depending on the type of application that you are developing, there will be certain application-specific scenarios. For example, if you're developing a navigation app, some scenarios that would be specific to your application would be looking for a particular location or address and then getting the directions for that address and actually navigating to that particular location.

So you should try running these scenarios on energy gauges for your applications, see what is the corresponding energy impact, then try to make improvements or optimization when you find the major problems pertaining to energy and then rerun these scenarios to ensure that Energy Gauges tells you that you're moving towards the lower energy impact or the green zone. So with that, let me move on to a demo where we'll try to run these scenarios on some sample applications so that it establishes a debugging workflow for you to debug your own set of applications.

So the first application that I'm going to try to debug is DemoBots. So let me launch DemoBots on my device using Xcode. So this is a simple game that we have developed. We expect the game to be utilizing only the CPU and GPU. Let me click on the Debug Navigator and click on the Energy Impact gauge. This is the first scenario that we're executing, which is the launch and idle scenario. You want to see what is the corresponding energy impact from executing this action on the application.

So here, we see that the overall score for our application is high. That is it has high average energy impact. So next, we want to see what are the components that we are trying to utilize. As expected, we are only utilizing the CPU and GPU. There are no unexpected components being utilized, which is great.

So next, let us look at which is the largest part of this pie chart and what it is that we can optimize first. So we see that our GPU component is being extensively used at about 88%. So if you try to bring about any optimization or improvement within the GPU in your usage in your application, that is going to give you maximum benefits. Some of the good principles that you could adhere to here are reducing the number of screen updates or reviewing your usage of blurs or using less opacity whenever possible. And this could bring down your GPU utilization and the corresponding energy impact generating from it.

Now let us perform another scenario which is backgrounding. Let me try to background this application. So we want to see whether it moves into the backgrounding state or immediately moves to the suspended state. So in this particular case, the application is immediately moved to the suspended state, which is great, because that lets the device actually sleep. And you're not incurring any energy cost on your device. Let us shift gears and move to another application. The second application that we are going to try to debug here is EnergyBuddy.

Let me launch EnergyBuddy on my device using Xcode. So this is a simple application which we have developed which lets you take pictures of energy meters. It gets the reading from that picture for the meter. It then accesses your core location and uses your location to get the weather for that particular location. All of this information is later stored in the database, which you can retrieve.

So let me click on the Debug Navigator and go to the Memory Impact gauge, sorry, the Energy Impact gauge. So here, this is our first scenario that we're executing, which is the launch and idle. So our -- From here, we see that right now our energy impact is zero, which is great. The only component that we are utilizing is CPU that was required for the launch. Now let us perform one application-specific scenario. Let me try to import a photo and see what is the corresponding impact from this particular action being executed on my application.

So when I import a photo, I'm going to accept one of the photos and allow EnergyBuddy to access location. So this generates a graph from the meter reading that it has got. So as we see in the instantaneous section here, on executing this particular action, my application is utilizing CPU for processing and it is also utilizing the location component.

So this was expected because we wanted as soon as we import this particular photo, it takes the location and then uses that location to get the weather information. However, here we can see that it is continuously accessing core location and that could be a leak within my code where I have left accessing core location continuously. So that is something that you can fix within your application and then try to rerun this particular scenario of importing a photo to ensure that your energy impact has gone down.

So now let us try backgrounding this application. So when I background this application, we want it to move into the suspended state as soon as possible. However, here we see that the application has moved to the background state and it continues to access location while in the background state. So this is not providing any utility to the user and this can definitely be optimized within the application.

We are accessing core location and that call is not getting ended and that's why core location is continuously being utilized resulting in the very high utilization for location as you can see in the pie chart. You also see a gray portion on the backgrounding section which is the static costs associated with keeping your device awake. So as long as your devices continues to be in the background state because of this application, there is going to be certain cost that is going to be built to your particular application.

So these are some of the scenarios that we want you to run on your applications when you're trying to debug it for energy issues, identify what are the scenarios which are meaningful to your particular application, run those scenarios using Energy Gauges, and see what does the report tell you about the energy impact from executing each one of them. Make the necessary improvements or optimization within your application. Use instruments to drill down deeper. And solve the problems pertaining to energy.

Rerun these scenarios in your application after you have improved your code and verify that Energy Gauges tells you that now you have moved towards the lower energy impact or the green zone. With that, I would like to hand it over to Daniel for the final thoughts and wrap-up of this presentation.

As you guys saw, you'll definitely want to check out Energy Gauges. It'll help you find great energy improvements to your apps. So let's wrap it up with some final thoughts. First, you'll want to use NSURL Session Background Session whenever applicable. It'll really help the system find the best time to do your work.

Next, make sure you minimize your use of continuous location. Remember that this will cause your device to stay awake. Next, avoid timers. If you need timers, set leeway to ensure that they're coalesced. And finally, use Energy Gauges. It'll definitely help you find great optimizations. Here're some related sessions. You'll definitely want to watch the videos for these. Thank you very much.