Profiling compute – Mobile Web Development

Profiling compute – Mobile Web Development


Now the final tool I want to show you today, is going to help you track down a lot of your compute performance problems, so this is actually the profile tabs on chrome dev tools, clicking this option will give you three options or more depending on what chrome decides to roll out in the future. The first one you need to take a look at is, Collect JavaScript CPU Profile. By hitting the Start button, what actually occurs is, Chrome is recording all of the application and JavaScript code that’s running right now. Hitting Stop actually gives us this beautiful chart that allows us to see where my JavaScript was going. Now, this is actually broken up into two areas. On the top here, you can actually see a generalization of spike of CPU time utilized, and on the bottom, these beautiful, beautiful colored line is actually what we call a flame chart. Scrolling my mouse cursor actually allows me to zoom in, and what you see is a treasure trove of information. This flamechart doesn’t just show us pretty rainbow pictures on the screen, but it actually represents a inverse call graph whose horizontal size represents how long a function took to execute. So for example you can see the animate function was called here, and then it called the run function, then the draw function, then another draw, and then another draw. And eventually we keep going up and up and up the chain. Of course, hovering over shows you the total time that these events took. And then where, in the name, shows you who actually called that function. Now you can see we have pillars of function calls. Basically, that’s the call graph going through. But between them we have this really interesting little program bar that no one seems to understand what’s going on there. What you’re looking at here, is that these tall pillars actually represent a frame of computation. So this is actually a request animation frame where the page is updated, scripts are run, everything’s drawn to your screen. And then when it’s done, it relinguishes control back over to Chrome. What you see here in the program bar, accounts for the time that the browser takes before it comes back and gives control to the game again. So you can see here that we’re actually giving about 12 milliseconds for Chrome to do it’s job, and then once we get back it takes about two milliseconds for up to update the scene, do any important calculations, and move onto the next frame.

Be the first to comment

Leave a Reply

Your email address will not be published.


*