Practical Web App Performance Problem Solving

Hi, I'm Jonathan and I'm a software architect at Vonage. I'm also a runner. This is me winning a half marathon. And this is relevant because today we'll be talking about runtime performance. So here's the proof that you can take my word on it. What is runtime performance? Let's see through an example. Garbage collection. Garbage collection is the process in javascript in which javascript takes objects that are not needed anymore and removes them from memory. That's in one sentence. What can be the problem with that? Let's see that. We have two arrays here, two functions. One is build array, which creates an array and iterates n times and pushes items to an array. This is build array 2. It pre-allocates the array and then iterates n times and puts the same items into the same invases. Two functions doing similar things, but let's see if they differ in something. Here we can see the profiling of these two functions. The build array took longer to run than build array 2. And we can actually use this profile to see why. If we go deeper, we can see that in build array, we had like 1,250 recurrences of minor garbage collection. If we look at build array 2, we see it's around 200. So this is a big difference. And this is in essence runtime performance. Profiling and optimizing functions to take less time to run. Why is it important? Let's take a really quick look on the event loop. The event loop is what's running our main thread. This is where the code of our application is running. If it is blocked, then our code is not running. The other codes need to run, for instance, on server side, an api response. Or in the browser, a user can't click anything. Or animations will be stuck. So this is in the browser. And this is in node.js. And again, the important thing to take from here is that you want the tasks to be as optimized as possible. And let's see how we can see the tasks and how we can optimize them. So this is a function. Something quite noticeable. It should be familiar for you. Instead of n, we have a million. So it creates an array of million elements. But we have the set interval. Set interval is a timer. And a timer is one of the things that add tasks to the event loop. So we can see that every second, something quite noticeable will be added to the event loop and will be ran as a task. Let's see it in a demo. This is our function here. It's running in the browser. We go to the performance tab, and we hit record. So we can record for around five seconds. So we should have around five repeats of this function. And we can see these bumps here. Okay. You can actually see these bumps here. And if we just look a bit, we can actually see this in the flame chart. These bumps are coming every second. This is our set interval. And we can see that it adds a task on every time. And the task is something quite noticeable. So we can actually see everything that happens during the runtime and analyze it for optimization. We have a summary tab that shows us, for instance, if we look at the whole runtime, it shows us how long our app was busy scripting versus idle. Or we can look at the call tree, for instance. Let's look at one task and see what happened during this task. Or we can look at the whole recording and look along all the calls for something quite noticeable, too. And you can see some minor GC. So this is the gist of profiling applications in the browser. Let's see how you can do this in node.js. In node.js, you have the Chrome inspect page. And you have to start your application with the dash dash inspect flag. The app is running. And you start the open dedicated dev tools for Node. Go to the profiler tab. Start profiling. Let's profile for around five seconds again. We stop profiling. And we see our bumps here again. And it's the same as it is in the browser. So if you know how to optimize in the browser, you can do it in node.js and vice versa. How can this help you in real life? Let's see a real life example. In an app we built, we used Cesium, which is kind of a 3d visualizer of the globe. And we had to put a lot of entities on this map. And this caused the UI to get stuck. So we profiled the application and we found out that two functions took a long time to run every frame. This is the updates of the label and the billboard. And we investigated these functions and we found out that if we add an update once dirty flag to the entities, only when we update them, we can optimize it so entities that did not get an update won't be processed by these functions. And the results are that from 50% of the time scripting, we went down to 2% of the time scripting and the app was saved and people could actually interact with it. So the main thread was not blocked. So to summarize, we showed the event loop and how it manages our main thread. So we don't want to block it. I can't stretch enough the importance of profiling while optimizing your runtime performance. And I really like you to try, learn it, and enjoy it. There's a lot to read about it. You can read it in my blog. You can read it in the Google web dev blog and lots of stuff around it on the internet. I hope you enjoyed it. And thank you.