One of the pleasures you will have when developing web projects with ARCore is the ease of debugging with Chrome. In fact, if you were doing a comparison, web project performance tooling would be ranked #2 on our platform list due to the capabilities of Chrome DevTools. Let's open up the spawn-at-surface.html web example from Chapter 5, Real-World Motion Tracking, and perform the following steps:

1. Start http-server on port 9999 in the Android folder, just like we did previously.
2. Pick an endpoint that matches your local network and write or copy it for later. Remember that your device and development machine need to be on the same network for this to work.
3. Launch the WebARCore app on your device and navigate to your selected endpoint. This will often look something like http://192.168.*.*:9999, where the *.* will be replaced by your development machine's specific IP.
4. With WebARCore, navigate to http://[YOUR IP]:9999/three.ar.js/examples/spawn-at-surface.html.
5. Connect your device to your dev machine, either remotely or with a USB cable.
6. Return to your machine and launch Chrome. Open the Developers tools with Ctrl + Shift + I (command + option + I on Mac).
7. Click on the Remote Devices tab and select your device. Then, click on the Inspect button to open another Chrome window with WebView of the app running on your device.

8. Click on the Performance tab and then select the Record button to start Profiling, as shown in the following screenshot:

9. Let the app run in your device with the Profiler running for around 30 seconds and then click on Stop. After you stop capturing the data, a profile session will expand in the Timeline window.

10. Click on the Call Tree tab at the top of the Summary window, as follows:

11. The Call Tree tab is where you can quickly identify function calls or sections of code that may be causing performance issues. In our example, we have drilled into the update function and can see that the bulk of the time spent inside this function is building the projection matrix with a call to updateProjectionMatrix. Since this call resides within the three.ar.js library, it is not something we will concern ourselves with.
12. Feel free to continue testing and profiling. Try setting several Andy models and see what impact this has on performance.

With any performance profiling, the thing you will want to quickly identify is spikes or areas where you see data peak. Identifying why these spikes take place will help you understand what activities can impact performance. Placing an Andy, for instance, will cause a spike due to the instantiation of a model into the scene. You will also want to closely watch how the app recovers from a spike. Does the app, for instance, fully recover, or only recover partially?

After identifying spikes, you will want to expand your view to cover the whole session. Then, you can expand the Call Tree and identify the most time-consuming methods. Chances are that if your app is spending 80% of its time in a single function, then you need to be very careful about what operations take place in that function. Finding and optimizing expensive methods can often get you very quick gains in app performance. While the tools are different, the same principles apply for all our development platforms.

We have just started to scratch the surface for what is possible with the DevTools. If you are doing any amount of web development, you will quickly get up to speed with these tools. In the next section, we will cover the Android profiling tools.