Doing the Least Amount of Work Possible: An Intro to Runtime Performance

Hey, everybody. My name is Ken and I am here today to talk about runtime performance. This is my talk, doing the least amount of work possible, which, while not only a performance tenet is a personal value that I hold.

So, let's get started by asking what is runtime performance. And you don't hear as much of it comparatively to some of the other stuff, right? A lot of the time when we're talking about performance, when you hear from, you know, I guess what would be devrels or platform advocates, the performance that they're advocating for is your load performance, right? Like a lot of conversion and retention and things like that. That all boils down to how fast your site loads and, you know, your time to interactive and things like that. You have all these lighthouse metrics and that's what's largely optimized for, right? You know, you're seeing things tooling like lighthouse scores, core web vitals now built into create React app. Things like page weight, right? Everyone's concerned with bundle splitting and keeping your bundle sizes in control. And that also funnels into things like the time it takes to parse JavaScript, like if you have a lot of JavaScript you're serving up, right? First contentful paints, right? You have these benchmarks of how fast your site's coming in and most importantly, I think, is time to interactive, which is the time until someone can actually start using your app or your site. They're in the clear to get going.

While that's super important metrics and it's very well documented, that's not what this talk is about. This is about staying interactive, right? Once you've loaded up, once you've covered your bases, depending on what your app or your site does, what you want to do at the end of the day is continue to be interactive after you've gotten them to that meaningful checkpoint, right? And the core piece of that is to not block your main thread.

In JavaScript, you have a main thread, and it's where a lot of the party goes on. And if you block it, you're going to see things like animations are going to jank out, you're going to be typing into inputs, and there's going to be lag. All things that adversely affect the UX of your site or app, and you don't want that. So the typical issues that you might see, things like computationally expensive tasks, if you have to operate on or clone a big bunch of objects or something like that, animations is where you'll see it. A lot of the time, you got to go and start typing or start trying to click something or do a hover to see it, but if you have an animation going on, you're going to see that almost immediately if it's done a certain way, so it's going to jank out. And it doesn't even have to be like, you know, 900,000 objects. You can have your whole site get janked out just by Reflow, Repaint, and Layout. I was looking at a site for a buddy the other day, and he didn't have any JavaScript, but the site was running slow. And it was the web animations API, it was just browser layout taking place. All right? You know, other things are parsing, right? If you're parsing large buffers or JSON, right, that takes time. That's a computationally expensive task. And my least favorite of all, which you probably have the least insight into and takes real detective work is memory leaks. They're devastating. But again, that's that becomes really apparent. Oftentimes not very quickly. You have to sit there for, you know, an hour, and now the thing slows down. And then you say, oh, boy, like, you know, you have like a CSS problem, you refresh, and you can say, I changed this, I changed that with a memory leak. You have to wait an hour just to reproduce it. It's rough.

So how do you know that you have a performance issue? So I mean, obviously, you write your profile, but a lot of the time, if it's actually an issue, you'll know. Like, you know, as far as you hear a lot of talk about premature optimization, things like that. If you have a performance issue, a lot of the time, it becomes pretty apparent. Your thing will be slow, you know, unless you get used to it being slow. But that's a whole other talk, right? Your best case scenario is you're going to see a lot of dropped frames and things like input delay, right? Those will be the main indicators that you're having a problem. Your worst case scenario is an aw snap, right? And then this is where it memed out, and you know, it's totally crashing your website. So those two points and anywhere in between, it's indicative that, you know, you should probably take a look at the code and think about optimizing it.

So how do you fix it? You've identified that there is a problem. You're not sure what it is, but how do you fix it? And I'll tell you right now that a lot of it is like detective work.

Performance is not prescriptive in the sense that I can't tell you a checklist of things like I can with, you know, like Lighthouse. I can't be like, well, you know, do you bundle splitting and put this stuff in the head and this stuff at the bottom. You know. A lot of the time it's a problem that you've created the way that you've coded it. And you have to untangle that, right? It's a thing that you have to get clever about. Sometimes it's the reality of the requirements of the app. And then you have to find a tradeoff or a sneaky way to do less work. Right? When you're optimizing for performance, if you want it to go better, you do as little work as possible. Not you personally, your application. You want to do the smallest amount of work possible to achieve your goal. Otherwise you have inefficiencies, and at scale they blow up. Right?

There are some semi-prescriptive things that I can get into. Right? Obviously it has to apply to your situation, but... Things like using a regular for loop. If you're saying, hey this takes too long, how can I make it go faster? Where can I get a little here? If you're sitting here getting all fancy with all of these chained maps and all this, this and that, if you do it in a regular for loop, at the scale where it would matter, you can absolutely get some of your time back using that. A lot of array operations, right? Like if you're doing a find in an array or something like that, right? One of your biggest enemies in performance optimization is iteration. Especially unnecessary iteration. So if you have an array of like 500,000 items, and you're gonna do a find on it, or you're do any of these array prototype operations that are gonna run through the entire thing until it either exits or completes, that's expensive, right? So if you have like an ID, say, I have this ID, I wanna find this row that has this ID. You can create a lookup table. And a lookup table is a stupid term for, I mean, maybe not a stupid term, but if, you know. It's an object, right, where the key, right, would be your key, like an ID, like the thing you wanna look for, right? And then you could have the value of that be the index position of your thing in the array, right? So it's a very cheap way to find that thing, right? So you're saying like, oh, well, I have to update thing ID equals this, say, hey, lookup where is it? And it's just, bap bap, bap bap, and then you're good to go. Rather than saying like, find with a predicate function that looks for the ID or something like that. Another thing that you wanna check out, especially, especially costly, is creating a bunch of new objects. And that's objects and arrays, right? There's a lot of fanciness going on in dev these days with ES6 or Next or whatever we're calling it these days, where you use spreads all the time and spreads create new objects, right? So if you're dealing with things on the magnitude scale of hundreds of thousands of things, and you're creating new objects, what that's gonna do is that's gonna force garbage collection and it's allocation costs as well, but that is gonna hose your stuff, right? If you can do a direct mutation, and I know that's a dirty word, but if you can do a direct mutation then you can see some savings. An alternative is to use something like Imr, where you have structural sharing, right? Where it's not performing a clone to do an update, right? It's not necessarily mutation or imperative, but it's a way to do it that's much cheaper. One thing that's really funny that I wanna talk about for a second is perceived performance, all right? So there's performance where things are actually slow and actually blocking the main thread, but there's also scenarios where you can make things feel faster without it actually ever being faster. And you could do that by turning off animation in a lot of cases, right? So if you, I had an app where I was redesigning it and people were like, wow, it is blazing fast right now. What did you do? And I just turned off animation, right? If you have this animated hover type thing, while it looks cool, right, the perception as you're going through is that it's slower. If everything is instant feedback, it feels faster. So perceived performance, you know, that's kind of like you go back to like the suspense with the loading spinner thing.

There's something to be said for perceived performance, especially in the UX area. Another thing I might go into is to avoid reflows and layouts. And I'll show that in a little bit, how that can happen. Yeah, you don't even need expensive things to be happening. If you're animating things or popping things in and out, and it is causing the browser to redraw, then that's not great. That's gonna—that doesn't even need computation because the browser redraw itself will jank everything out.

Caching is an easy way to improve your runtime performance. A lot of the time, you'll see on every single render, people will call a date format or something like that, and a date format is expensive, or create a date object. If you can memoize that, if they're not changing and you don't expect to rack up this 2GB cache of date objects, then what you're doing is a sneaky trick, where you're saying, I'm gonna format these dates once, and then any subsequent call to format for that date, if we're rendering this, if we're clicking a checkbox and it's just enabled or not, it has nothing to do with the date changing. It's gonna serve up the string BAP BAP, and you're not gonna take this hit on every single item getting date formatted.

And then there's minutiae. And the minutiae, a lot of the time, it's overkill. But when you're really grabbing for stuff, especially in large row count iteration kind of things, doing something like if you're gonna delete a bunch of things out of an object, it's way faster to set it to undefined instead of using the actual delete keyword. And like anything else in performance, there's a trade-off, where those things are still gonna come up and it has own property or something like that. But then you just have to be wary of it, because there is a trade-off for everything.

So, I wanna talk just for probably the rest of this talk about profiling, because that's how you're gonna solve these issues. And outside of the semi-prescriptive stuff that I just mentioned, you wanna find your issue and identify it so you can begin architecting a solution to it, right? And some of the tools that I'm gonna show and that we're gonna use are the Chrome performance tab, the Chrome memory tab for memory leaks, your performance monitor, which is very helpful with CPU, and the user timings API, which is amazing. So let's learn how to use dev tools a little bit. So I have this little create React app business going on here. And in here I'm gonna create a million rows in an array here in this initial list. And then we're just gonna push them, right? And then I was gonna Live code it, but I'm not gonna do that right now because we're running out of time. And I want to get to this. So we have this list, this initial list, million things, right? It's got an ID and a value that's random. And then we're just going to use that as state here with the initial value, right? Then on mount, right. do an interval. Every 500 milliseconds, what I'm going to do is I'm going to call set list with our list, right. So this is going to this is a set state, right with the list. I'm going to spread out that list, clone it to create this new list. And then I'm going to iterate through and spread the old values in in this spread. Remember what I said about the spreads, so this now it'll get its ID, which, you know, Ridiculous because it's just the index, but it's contrived bear with me.

And then we're just going to add a new value and then we're going to return the new list. So we're updating that list here every 500 milliseconds of a million things, right? So let's take a look at this. And I'm going to show you how to how do we how do we profile this, right?

So we have our slow app here. So I'm going to bust open my dev tools here. And we're going to we're going to take a look, because we're gonna learn how to read this today. You hit record, right, and it's going to start profiling your runtime performance. You hit stop. And now we can look in here. And if you see, so first of all, this is your main thread. I'm going to just walk through this for a second. This is your your raster your GPU your compositor. If you have workers that will be on a separate line. Now it's having a really bad time here. I might drop that countdown.

So each one of these right here is one of those updates that you're seeing. And it is going to get it's going to go from parent to child in the call, right? So you're going to see I have this anonymous function here. It's going to run through a bunch of internal react stuff. It's going to try to render app right in response to the state thing. We get down here into our state reducer. This is the actual internals of that. And then you're going to see this. These are all anonymous because it's not a named function. The reducer on that set list. But you're seeing this and when we're creating that many new objects, that's where you get this garbage collection. That's taking 10 milliseconds, right? So in order to do that, right? We're looking at 375 milliseconds. When you look up here and you see this red up here, that means when you're actually blocked, right? And you'll see down here, it's going to say total blocking time. So it'll show you that. And you have an enormous amount of missed frames in here. The red is bad. And I mean, if we go and look, I mean, I think it's having a pretty bad time right now.

So we can go to more tools and we can go to performance monitor, right? And it's gonna tell us that we're almost at, you know, 100% CPU here and there. The heap is humonganoid, not that many dom nodes.

So let's go back for a second. I'm going to take this down to 20,000. All right. And then we can come over here and it's not so bad anymore. Orders of magnitude less, but it's still not great. We're gonna come in, we're gonna run a profile again. All right. So for less things it's not as bad, but it's still pretty bad. It's 60 milliseconds, that's like several dropped frames. We can go and look at memory here. And this is how you debug memory leaks, right? If you take a snapshot here, a heap snapshot. Um, one common way that I'll do that. There's a lot of objects in here, so it's thinking and I'm screen sharing. God, relax. Yeah, so you have here. And then what you can do is you can, sort by shallow or retained size. And then if you take subsequent snapshots, you can go through and you can see what is what? What is happening? What's more, you can even go and you can, um, if you do two, right, there's a good diff. Right? I'm not going to do it again because it takes a while to do, but so this, you can see objects allocated before snapshots. You can look at the diffs of, you know, what is what is accumulating in here. And that's pretty helpful. Um, wait.

So here, right. We know that our problem is, you know, in this anonymous function. But the problem is, is that this kind of gets like quantized into, um, these blocks. Uh, so what we'd want to do is take a look at the minutiae and the way that we would do that, what I'm going to do is I'm going to do 5,000 just so it's not so devastating. Um, but what we can do here is we're going to use what's called the user timings API. And it's amazing. So you can do performance.mark, right? And we'll call it list clone start.

And then we can come down here and I can say performance dot mark, list clone stop. Right? And then right here I can say for each one of these, well, before I do that I'll say performance dot measure, right? And you have your measure name, so we're going to call it list clone. And then you have your beginning and end, which are going to be list clone start. And list clone stop. Down here I'll say performance dot mark and we'll just call this one, two, right? We'll call it one and two, right? And I can hit save there, then we can come back here. It's probably going to yell at me. Let's refresh you, come back here. And, you know, rather than that bucketing into the, the wild stuff, you know, we're actually gonna be able to see granularly what's happening here, which is going to help you and your profiling. This might take a second. You can do it. You can do it, I believe in you. All right, I'm gonna do a quicker one. Nobody's got time for that. Come here, you. Okay, now, now we're talking business. Okay, so here now, above main, you see a new thing called timings, right? And previously, when we looked over here, and we look down here, and we see these anonymous, right, that's where it topped out. Now you get to see granularly what's happening in here. Right? So you have the mark measure, that's in there. But if if we go up top into timings here, we can zoom in. And we can see exactly how long these things take. Right? Like, this is an iteration, right? So you see the one, two, iteration, and that's in that's in microseconds. I'm trying to see if I could see a one of the clones. It's probably in the beginning here. Yeah, so you see the list clone takes a fraction of a millisecond. Obviously, if we were up at a million, there'd be quite a few of these, and I probably just do the clone rather than the individual ones. But yeah, this is, this is a great way where you can granularly take a look at what's causing problems. Now I'm already over time, but before I bounce, I'm going to show you an example of when it's not even JavaScript that's doing it. Right? So before, and let's take a look at like, when we go here, right, you're seeing some information in the summary right here, and then it's going to say the aggregated time and it's almost all scripting, right? So that's telling you like, your JavaScript's the problem but a lot of the time JavaScript is not the only culprit here. So we have this rascal rotating and this animation takes place on a different thread, so it's not a problem, right? It's also using transform, right? So it's composited, which means it's drawn as like a layer on top of your website. When you use like translate or rotate, it's not actually updating layout, it's not moving things around on the screen it's kind of just like in place.

So if you translate, right, like the area where it is is still there. It's just up, right? Because it's being composited, right? So you don't take the perf hit there and then that's why they say to use the transforms if you don't want it to be janky. But if I come here and I do a layout forcing thing, like if I were to animate height for example, so if I were to come here and I was going to say height and we're going to go like 200 pixels height to 400 pixels, right? And we come over here, all right, you're going to see it kind of jank out, right? You might not be able to see it on the stream, but what's happening is when this gets bigger, every single time the browser's internal layout system has to recalculate where all this shit is supposed to go. So if I come back over here and now we profile this, it's going to tell a very different story. Probably not as clearly as it did with the more expensive things. But if we come in here, right? What you're going to see is a lot of green and purple. And what that is and see all these drop frames? What's happening is this is style recalculation and layout and then repainting, which means the browser constantly has to redraw the entire thing that you're looking at because the height is changing, which is invalidating the layout. And you can see in here it's saying rendering, painting, and not just that, you could see the compositor here is going absolutely bananas and you're getting GPU hits over here on the paints. You don't need JavaScript to destroy your runtime performance. You can do that all your own just with CSS.

So I hope that today I've done a good job of putting the spotlight on runtime performance and also explaining dev tools a little bit better and giving the tools you need to make your sites continue to stay interactive and fast.

Thanks so much, everybody. Awesome. Thank you so much for that cool talk. I really, really enjoyed it. I hope you enjoyed it too. The awesome Ken Weaver.

Let's go and check out a question that Ken asked us earlier. So Ken asked if you have used the performance panel in Chrome DevTools. And the poll is yes! Well, 64% of you said yes, but you're not 100% sure on how it works. 22% of you know or said yes, and you know how it works. And 14% said no. I highly recommend them. I think they're awesome. So definitely, try them. But before we go on, I'm going to invite Ken to answer your awesome questions. Ken, how are you doing? I'm outstanding. How are you doing? I'm doing good, I'm doing good. You know what? I love your setup. I love the vibes. I can just picture some lo-fi beats playing around in the background. Just a quick question. This is just for me. What's your favorite kind of music to play while you're just chilling? When I'm chilling or when I'm coding? All. Both. All right. So if I'm coding, I don't like stuff with words in it, right? So I'll listen to like lo-fi beats or like the Westworld soundtrack, that sort of thing. Trent Reznor albums or something. Because it doesn't take much to process. But if I'm just chilling, like usually like some fun trap music or something.

Awesome. Nice, nice. I could talk about music with you all day. But we've got some actual developer questions that I want to answer. The first one I find it hilarious, but I'm still going to ask it anyway. If you suspect a memory leak, do you try to debug it or do you smash it with a code review hammer or do something else? What's the first approach to deal with it? If I suspect a memory leak, I go get like a glass of water or coffee or something. Because most of the time, when I encounter memory leaks, you know, it's the sort of thing where you have to sit there for like 45 minutes to reproduce it. You know, like very rarely do it like one of these things like just like, you know, you get the OSNAP and the browser crashes, right. It's always this thing where like over 45 minutes it grinds the halt. So, like, all right, well, you know, I'm gonna sit here and do something else while snapshotting here and there and then we can see what's building up. I've definitely been in that position trying to hunt it down before. And it can suck sometimes.

Have we got another question from W Warrior? What do you think about libraries like Immutable.js which create new objects by design? I mean, Immutable is cool but, Immer is pretty much my go to now. You answered the second question which was, do you see any alternatives? Is there anything specific you like about it? It's pretty straightforward, right? Like, you know, you use the produce function and then, you know, mutatively edit whatever you want to do and it applies it. Nice, nice. So we've got another, sorry, say again? I was just saying it's simple and it's fast. What more can you want? Nice.

We've got another question from Pop Linguy. Could Firefox performance tools be a concurrent of Chrome developer tools or Chrome dev tools? I think comparing the two. I honestly couldn't speak to it. I haven't used Firefox in quite some time. But the last I checked, you know, they do have some interesting features. Same can be said for Safari. There's some interesting graphic debugging stuff in there too, but I spend 99.9% of my time in Chrome. Yeah, same as well.

I'm a big fan of Chrome. Someone asked about just a different memory leaks that you fixed. Have you ever seen any sort of common similarities or common trends across them? Well, I mean, like one thing that happens a lot is like listeners, right? Like if you add listeners and then don't remove them, that's one that happens a lot. Other times, you know, you can just have something that's building up over time, right? So say you cache some data, right, every time you load a page, right? But if it's a single-page app and there's hundreds of pages, you know, if you navigate through hundreds of pages and that cache isn't periodically cleared, right, depending on what's in there, right? It's not just like markup, but like, if you're loading like 500,000 row datasets for each thing and, you know, you're navigating between those, eventually that'll build up. Other times, it's kind of just like iteration and timers, right? If you have like real-time data and you're iterating through things, little caches and stores can build up.

Cool. We've got another question. It's another joke question, but, you know, I feel obligated to read it out, so I'm gonna go for it. This is, do you do a regular check of your memory profile or do you wait for problems to come knocking at your door? Not, I mean, it depends, right? Like if I'm making like a Ken Wheeler joke, like if I'm making like a kenwheeler.blog I'm not really checking the CPU on that, but if I'm making like a, like a high-performance canvas control or something like that, like, I'm definitely going to pre-emptively look at where the CPU is, like in early to mid-stage development just to make sure, you know, set baselines so that later on, as it gets more complex, right? You can say like, you know, what are we getting and what are we losing? That makes sense.

And the last question, someone, Alex, has said thank you for sharing how animations can be a performance hit. Animations can still be really important though, so the answer, so they're asking, should they just use animation sparingly or are there other techniques for having performance animations? You know, I think that there's, I don't think all animations are bad. I think the ones you need to watch out for are animations that are tied to user interactivity, right? So like if you're like moving through, if you're highlighting something or highlighting rows or something like that, that kind of thing, I wouldn't animate that because it's putting a buffer on the feedback to the action, right? But I mean, if you want to have like a Josh Camus, like whimsy style animation, that's, yeah, go ahead. That's awesome. You know, that's not necessarily directly tied to the that sort of thing, right? Yeah, no, I get you, I get you.

And right before we go, because I know we're running out of time, but you're off to do a DJ set. Is there anything you can tell us about what to look forward to for your music set? Not really, I'm just gonna play some shit that I like. I mean, you know, it's not like, my Porter Robinson up here and I'm just gonna, you know, drink wine and play some nice beats, everybody else should grab a beverage. Well, once I'm done, I'm gonna go and grab some wine and listen to some beats. Thank you so much for hanging out with us. I love the tour. And hopefully I get to see you again soon. I'm definitely going to check out the music you'll be playing. Thank you so much and I'll see you around. Thank you.