Search This Blog

Thursday, May 12, 2016

JS Profiling

In order to make your game fluid / fast, you should ideally reach around 60 FPS. Ensuring about 60 FPS also allows to ensure that all players will play with the same pace.

The first step in this direction is to see how well your game behave, and for this a little "gadget" could be handy:

http://darsa.in/fpsmeter/

This little tool shows a graph and a few values to see if your game manage to keep the needed speed.

Now that you have a view of your current speed, you may as me have the issue that the game is not optimized enough, however if your code is not just a few lines of code you may start to wonder what takes time.

In the old days the solution was to put a "stop watch" around some critical areas and see how long those areas took. Today even browsers starts to have really good debugging / profiling tools. I will here discuss only Chrome but for most parts you can use any other browser (maybe with some additional plugins).

To start the debugger press simply F12:


You will see the debugger contains loads of "tabs" and each of those is specialized in a different task. I usually end up using a lot the "Source" tab as it allows me to see my JS / TS code, put breakpoints and see how it is going within my code.

In this case as we want to debug the performances of the game we will use the "Profiles" tab. Once you click on the "Profiles" tab, you are greeted with a selection of the type of profiling you want to run. To see which function takes more time choose "Collect JS CPU Profile" and click the "Start" button.

At this point use your game as you usually do. But don't spend too much time on it. I would say about 10-20 sec should be enough to collect all the data you need. Once you decide you collected enough data click on the "Stop" button of the profiler, and here the magic happens:


On top of the result page, you will see a gray bar allowing to choose a few things. The first button allows to choose different type of views for the collected data, I find personally "Tree (Top Down)" more intuitive to read as it represents also the calls of your code. In my case, before I started to optimize, you see that 67.9% of the time is spent inside Play.GameLoop, expanding it, I see that 49% of the total time is within WorldRender.Render and digging again I find WorldArea.GetObjects taking 31%.

Clearly the I should work on this GetObjects function and see if I can speed up my soft. After nearly a day of work, I managed indeed to speed up a lot my engine:


From a first impression you may think: "Wait! We still have about 62% inside the Play.GameLoop!" yes, that's true, however if I dig down you see that now inside my WorldRender.Render most of the time is consumed by "drawImage" which is nothing else as the Canvas 2D drawImage function itself. This function cannot be directly optimized as it's an API call and therefore I indeed speed up my soft.

Before optimization I was about 20-30 FPS and now I run about 58-60 FPS, which is nearly a 2x improvement.

As you see, using the debugging / profiling tools offered by the browsers can indeed help you pin point where your soft is eating up resources / time. Just a quick note, if you see that all the time is eat up by a single function but you don't get more info than that, simply split your function in smaller pieces and the profiler will then be able to tell you in which of this piece the time is spent.

No comments:

Post a Comment