mergeconflict317 === [00:00:00] James: Frank Frank Frank, today, I want to talk about the hottest topic that everybody is talking about. Not the heat index in your local city, state, or country. No. But performance, performance performance that developers, developers, developers care about Frank. But before that, can we get a drone update? Frank? What's the situation . [00:00:25] Frank: Did you just make light of a very hot situation out here? I'm melting James. That that's the drone situation. No, uh, I did. I wanted to give an update to everyone if anyone's cares. my pixie drone has yet. To be found. James, uh, went on a fun swim though for my birthday, went for a swim to try to find the drone even bought a snorkel, went snorkel in, did my underwater little got my badge, my little scout badge, uh, did, but didn't come up with a drone, no drone. It's it's in like a really deep part, but I got to swim for a while. That was fun. [00:01:02] James: Oh, that's nice. And that way you stayed. [00:01:06] Frank: Stayed. Cool. In fact, the water's a little chilly, especially deep down where the drone is. Look, I'm not giving up this mission either though we are continuing the drone mission. Um, you know, probably for the next year, until I finally give up on it or at least when the weather starts getting cool again, that's when I'll give up on finding the drone, but until then, it's still not lost. It's just misplaced [00:01:27] James: because here's the thing about the Jerome it's out there. Frank it's it's there. Somewhere. [00:01:34] Frank: I don't think it disintegrated. I don't think in fish ate it. So it's there. The plants ate it. Um, I'm gonna blame the plants, but, um, yeah, it's there. And look, this is just my civic duty of ridding the canal of garbage. So I, I left some garbage in it. I unintentionally littered. I gotta go find it. The big question is, will I get a scoop of license out of this? . Or will I, you know, hire a salvage team for $2,000 to go find my $200 drone? No, that probably won't happen, but I might start looking into the scuba certification. [00:02:09] James: I like that scuba certification would be super cool. I have a lot of friends with scuba and then, yeah, you could just be down there for a long, long time. I like it. Yeah. Well, keep us up to date. As the drone exploration continues. I've been so scared. I haven't even removed it from my office, so it just sits there. It's looking for, I I'm too worried that it's gonna melt. Not not stink. It's gonna melt in this heat. [00:02:31] Frank: Well, it's, it's bright colored. It reflects a little, I mean, everything's melting in this heat. I can't believe my computers are still functioning. Honestly, , I'm not functioning, but somehow the computers are tripping on. I was kind of hoping they would just turn themselves off. But no, [00:02:46] James: I like it. Uh, okay. Well today, Frank, I wanna talk about performance cuz I have a lot of things on my chest in and around this. Not only. Graphics and frameworks, but I wanna talk about CPUs as well, but before we do, let's kick it off with our amazing sponsor because it's a new. It's sync fusion. Yes. You know, you love sync fusion, cuz I love them as well. Sync fusion gives you hundreds of the world's best UI components for all of your web, desktop and mobile applications. No matter what you're building, they have something absolutely spectacular for you. Blazer, flutter, asb.net core JavaScript, angular react view. Donna Maui. Did I already say that I might have Xin UWP JavaScript, win forms. WPF win. All the things they got, all amazing charts, graphs, controls, widgets, thingies, all these other things, including my favorite bit and piece file formats, including Excel, PDF word, and PowerPoint and viewers and all of this super rad stuff. You gotta check out the brand new controls for all these amazing platforms. By going to sync fusion.com/merge conflict@syncfusion.com slash merge conflict. Thanks, sync fusion for sponsor. This week's PA [00:03:58] Frank: thank you. Sake, fusion. And that is an amazing list. I, I, I know you went fast, but that was fun. All, all the different, uh, platforms they support. Pretty impressive. It's [00:04:08] James: impressive. I gotta say, um, alright. Here's where this entire thing comes from. There's two parts, part one, Frank. I wanna talk about the M two because it immediately, no, I know what you're saying. I don't [00:04:23] Frank: I've I've heard the rumors, James. I've heard the rumors. Okay, please continue. I wanna talk [00:04:27] James: about the M two, because if you've watched or listened any review that talk about perf and apple talks about perf, especially here. Now I have an M one MacBook air. As of Frank, we did not get the pro or the max or all these other things. Although I think those are faster when it comes to M. There's all these charts, all these graph, how fast it is, but what I am hearing when it comes to real world, and this is where I think it gets important from a developer perspective later on in this conversation is real world usage, because what apple tells you, what all the other comp, what the Googles, the Microsoft's, the Lenovos, all these companies, the Intels, the AMDs. Are these benchmarks, right. They finally craft and tune and do different things right here and there. And they set off to attempt to, you know, Make sure that they have these real world tests, real world and quotes here. These performance benchmarks that are, that are going off and can measure things. So you can run the same benchmark against the M one versus the M two versus the max versus the pro. And this is the same thing that we've done in graphics cards forever. We've had these benchmarks. I do all these things, cell phones, same thing. And there's all these numbers, Frank. And when I heard about the M two heard about the new MacBook air, which is a beautiful redesign, which I was more excited about. What it came down to. What I have heard is real world practice that, yes, it's a little bit faster, but it's not like it's revolutionary faster from going from an M one to an M two, because the app, you know, applications, the models, all the other things, right. In general, it's kind of similar in a way. Hmm. Even though you have all these, you have all these benchmarks, all these things, telling you all the other things, but real world, right. Mm-hmm so are we all sitting there? Izing videos all day. You know what I mean? Yeah. Or what are we doing? I'm recording Zencaster and I have like five tabs. [00:06:31] Frank: Yeah, real world performance. I feel like plateaued somewhere around 2005. I feel like everything still runs at roughly about the same speed it always has. Yeah. The video definition's gotten a little better. Maybe the music quality's a little better. There's more pixels on my screen, but apps roughly. Go about the same speed as they did in 2005. So when we get into real world, that's why I said bag of worms like that. That's a whole, we could say a million things about that. I wanna go way back to what you were saying about the reasons to create benchmarks. There's a lot of reasons to create benchmarks. If you are a. Good company. You create benchmarks that represent your user scenarios and you optimize those that's so that you can be good, honest engineers and make sure that you're working on the problems that your customers actually face. That's the good kind of benchmark. And then there's the other terrible ones, the industry benchmarks, which are, you have to run your software through industry benchmarks so that you can compare your product to other people's products. And you don't wanna do it, but you have to do it. And then you get into that ugly cycle of the engineers are optimizing for the industry benchmarks instead of your internal benchmarks. Uh, but you have to do that because the sales people say, you have to do that because you know, our, our sales are down this quarter. So you got all of those pressures and then you have the third kind of wonderful benchmark, which is, I want. Attack a competitor benchmark and this is the, oh, look, my platform's really good at this one thing. I'm gonna invent a new benchmark and I'm gonna show how all these other things, uh, these different products, different skateboards, different pieces of software, uh, see how all they compare against this benchmark. That really only privileges me. So those are all the terrible reasons to create benchmarks. And that's all a light. The real world. And that's the hardest benchmark of all of them, because we all dunno what we're talking about when we say the real world. [00:08:24] James: Yeah. Coming from a developer perspective, you know, one of my favorite benchmarks would be like benchmark.net. So benchmark.net.org tool tool and the tool tool. Yeah. So it's a, it's a Don net library for benchmarking and this actually adopted by the runtime and about seven thousand.net projects. and, and this is good because what you're attempting to do. Is benchmark your own library. So Frank puts out SQL dash net. He's doing all this code. What he would do is he could create a benchmark, run the benchmark and say with. Different versions of.net, but also as he's upgrading, you know, SQLite dash net, what is the, the ratio? What is the performance? The mean? The ups and downs based on as he's adding new features or making changes here and there, right? Because there's also performance. He could have the same code. The performance implications might be different on Donnet five versus Don SX versus do net seven because all of those have different improvements and he could tweak and tune and do these things. So Frank's just trying to finally optimize and tune his library. He may decide to go with a testing or a benchmarking library such as this just so he makes sure that he's writing tight performant code. Have you ever done this in your applica in, in your libraries or even your application? I guess you could do this too. [00:09:45] Frank: Literally everything, everything I benchmark, uh, I, I am a performance freak. , there's nothing, I hate more in the world than, uh, losing performance to something a little bit dumb. So I often do benchmarks just as sanity checks, like as things going as fast as I think it should be for some things it's really important. Um, I'll have unit tests that fail if they run for more than two seconds, you know, things like that because I have timed criteria. Other ones are a little bit looser, like in SQL light. I have, um, basically it's not a unit test, but I'm using a unit test framework and then I'm running a benchmark inside the unit test framework, and I'm just bashing on the API. In a nasty way for multiple threads and making sure that it survives and making sure that it, it completes in a reasonable amount of time. So benchmarking is everywhere and tools like benchmark.net are super cool for micro benchmarking. We always call it where like the function you're trying to measure is so small and so fast already that it's really hard to measure. If you have something that's slow, it's really easy to measure. You do a date time in the beginning, you do a date time at the end and you subtract, subtract it to hello. You have a benchmark. Um, but if, if that time gets really fast, then you want to use a tool like, uh, benchmark.net. But this, this all goes along with profiling, your code and all that kind of stuff. So it's like you create a benchmark. You say this thing should be able to run within two seconds and then if it doesn't, then you get your profiler around and you start fixing it. James, I could make a whole living, just doing. Instead of developing new apps and adding features, cuz that's just, I think like a fun kind of addictive part of the job. Try to avoid [00:11:26] James: sometimes yeah, I agree with that. I think that I've failed in all aspects to benchmark anything only because while am a library developer, I don't have libraries that necessarily. [00:11:45] Frank: Let me interrupt. Okay. Because like, what you're gonna say is if it's fast enough, it's fast enough. Like , you only benchmark something when you notice it's not fast enough. So you, you were about to say something about your libraries and how they interact with the operating system or something. But I just wanna, I wanna override you and just say, what you're saying is they're fast enough. They're fine. I don't need to benchmark them because you click the button and the thing happens or it's doing a network call and you're really just waiting on the network or something like. [00:12:12] James: Yeah. Yeah. That makes sense. Yeah. And, and true. It's like if I was, and it is almost hard to benchmark because I'm calling those APIs, right. So I'm calling the app store APIs who do different things like that. Mm-hmm [00:12:25] Frank: uh, can I tell you a cool new benchmarker out? Um, yeah, this is for, I I'm gonna get my machine learning into this episode. I'm really excited a new feature in iOS 16 and X code, whatever we're up to. Um, You can take a core ML model and something that was always kind of hard about core ML models. You really never understood how fast it was gonna be on the device. You know, it was really hard to translate from whatever GPU you train that model on to like, is this thing gonna be at all fast on the device? And. Apple's added a really cool feature where you can just open a core ML model in Xcode and click a button and it just runs the model on the device, or whatever's connected to your computer and gives you a performance report back. Now it's not a benchmark because you're not trying to hit a very specific time or maybe you are, but it's not automated, you know? Um, but at least it's giving you that report. I guess it's more of a profiler now that I'm talking about. I'm talking myself in circles. But at least, uh, you get that time of execution. That is what you really wanna know. Is this model gonna run in one second, a half, a second or a quarter of a second? And it'll even tell you, um, which parts of the network ran on CPU GPU or the, um, apple neural engine. Oh, so it's, it's really nice because before it was. Black box, but now Apple's fine. We've given us a way to benchmark it, profile it and see into the details. Really it's gonna help with app development. [00:14:01] James: Yeah, that's really cool. I like that. There's, you know, you're kinda making a good point here is there's different benchmarks for different applications, right? If you are a graphics card, the benchmarks, and what you care about are probably different than the benchmarks of your library versus the benchmarks of what you're talking about for machine learning versus the benchmarks for a game engine, for example. Yeah. Right. And, um, drawing to canvas or doing other things like that and of. Even different if you're a UI framework, right. At the same time, say I brought that around Frank till I did it. um, I think that those are all different, important aspects. The, the, the real world part of any of those things are also different based on the use case. Okay. Because in the scenario of the machine learning one, there is a real world, um, Implication based on those benchmarks, which is that you can process more things faster, which then saves you more money. I think that makes mm-hmm is that's correct. Right. Um, [00:15:01] Frank: or makes it possible at all. If you're trying to do like a video app and it takes five seconds for every frame, it's that video anymore, you know, you, you gotta benchmark benchmark and get it down in speed until it's somewhat real [00:15:15] James: time. Yeah. I like that. That's a, that's a great point. And. If you're like a runtime or a library, you know, your users are gonna be using this. You wanna make sure their apps or computation is, is fast. Now, if you're, uh, uh, a graphics card, Then you care about there's a whole bunch of different applications that are important, including running and izing different things for games. So you, as a consumer, you care about those graphic specs because you want to shove it into your machine. You want your games to look prettier and run more and faster frames for a second is really what you wanna get down to at that point is highest graphics levels best, you know? Yeah. FPS as. [00:15:59] Frank: You have some apps that have to do it in multiple regions? Let me bring up ice circuit. yeah. Ice circuit is a simulator and it's a renderer, you know, they're kind of two different things. They share data, obviously. Um, but the simulator. Has to run at something like 40,000 frames per second. So there is a whole style of a programming that I adopt because that code needs to run faster, a hundred thousand frames per second. That code needs to run fast. The renderer, the thing that's actually drawing that also needs to be fast, but relative to the other one, it needs to be 60 frames per second, or 120 frames per second are some of these devices even higher. But, um, . Even that's hard to achieve, but you, you can get these mixed worlds like games in general are only trying to hit that 60 frames per second, but then, you know, you might be doing some, uh, stock trading, some high frequency stock trading, and that needs to be run fast. You might be doing simulations, might be doing neural networks. So even within one app, you have these different time domains. This part should be this fast. That part should be that fast. And then also with the ninth circuit, you have the. Time domain, which is the user interface, the buttons and the text boxes, and those things run at, you know, whatever they run at whatever the operating system can whatever's left [00:17:18] James: well, and that's the most important part that I, I think about when I think about performance, cuz the types of apps that I build numbers on a screen, they update like every half a second, every second so my frames per second are. 1.5, that , that's, that's what I'm going for. Frank is like a single frame for a second. So now there's a lot of, there's a lot of logic that's being crunched to make sure that, that I'm able to execute my code, to make sure that the UI can be updated in that amount of time. Now that's not to say I have other apps where like you're scrolling and you're, you're pulling in you're rendering things and the framework needs to be fast as well. But to your point, even inside of a, of a, a, a game or eye circuit, or, um, even my cycling applications, the there's many different elements that have different types of importance and the, the way and the underlying technology that goes about rendering that is gonna have different performance implications. So, for example, in your case with I circuit. Um, your, are you just using scene, scene view and scene kit? Oh, [00:18:33] Frank: no. Uh, well, oh, say sorry. In I circuit 3d. Yes, I am using scene kits. Scene view. And that's a renderer that runs at about 60 frames per second. I try to update it about 60 frames per second. Um, but uh, original ice circuit, the 2d one in the early days, it was released for the, you know, the very first iPad. So was that iOS 3.2 ish or something like that? Mm-hmm . I had a Dickens of a time getting any performance outta the render. Um, back then you had two options, open GL and core graphics. Mm-hmm and I couldn't get the quality I wanted outta open GL and core graphics was deadly slow. And so I spent a lot of time, um, Um, profiling benchmarking all the above. A lot of old hacks are still in that code base to make sure it ran smoothly on old iPads. And that these days now that we're putting M one processors into iPads, like, well, it's good enough that I can make a 3d version of the app, but I have to say like, at least for the first few years, uh, the, the rendering engine was a really hard struggle in the app. These days, the mobile hardware is so good. you can get away with a lot. Bad [00:19:45] James: code well, and the renderers under the hood and the frameworks in which you're building have also improved too. So you have to then think to yourself, well, how many objects do I need on my screen? How fast do I need it to refresh? And can I achieve that performance? And then there are the other parts of your application. Let's say the setting screen, where you can buy upgrades or you can, you know, back up data. You're like, all right, cool. You know what I mean? Yeah. Like how important is that part that it actually, you know, is the most crazy performant benchmark high-end thing in the entire world. You're like, it works as exp like as a user. Yeah. Cause cuz to me, when I think of UI, I, I, you know, even though I come from a video game background, our goals, 60 frames per second, That was always, our goal was run it 60 frames per second, and you're good. Um, you know, and you wanna lock it and the thing too, with, with engines and framers, you wanna lock it in, in a specific thing. You don't want dips if your game mm-hmm or your, your engine in ice circuit runs at 60 frames per second, run it at 60 frames per second. And it can't dip. If it is gonna, if you can't achieve 60, lock it at 30, it's better to have a. Frame frame rate than non constant, right? So that's when people see hiccups in UI or other things like that, that's what's happening is like there's a delay in the rendering loop and you don't want that. You don't want these hiccups that are happening even in normal UI. But when I think of my benchmarking and my user interface, for example, in the, my cadence app or the my stream timer app I go does when I click a button. Does it do the thing and the amount of time that I would expect for it to do the thing which is near and, you know, within X milliseconds pretty much, right. I click a button and it should react pretty much immediately that that's what users expect is when I click something, something happens. And if that happens, then to me, mission accomplished, I actually don't care if something is capable of, of, of rendering. 5 billion graphical elements on the screen. At one point, if for my application, what matters is, you know, X thing, because what it comes down to is what you just said. Was it OpenGL, was it core graphics now? Is it ski as is something else says, what is the best tool for the job, for your application type? And in that instance, Those benchmarks are good indicators of what the thing can do at some predetermined thing that somebody created, but does it actually apply to your running application? And I think that's, what's important. [00:22:31] Frank: Mm-hmm uh, it's, it's that classic magic trick too, of, um, it, it, it, your operation doesn't have to complete immediately, but you have to update the user interface immediately and then people can handle a tiny little spinner for a second or two, you know, it's fine. It's fine. I think there is one distinction to be made. I agree with everything you just said, but of course I'm gonna disagree now because that's what I do, but okay. , it's just a small distinction and that comes into actual energy use. Let's take the simplest app. I could ever think of it. Just a, it just displays a single number on one screen simplest app ever. And it updates that number. Once a second, there is a difference between an app that use. Next to no CPU. And then on the one second dot does a little burst to CPU and then goes back to ID versus an app that's cranking on the CPU and just barely managing to update that number. Once a second, they have com the user interface is identical. There's a number that's updating once a second, but the power usage is completely different between the two. Obviously you wanna be the app that's sitting there idle all the time, except for those first brief bursts where you actually have to do something and then you should go back to idle. There are a lot of apps and a lot of game engines. I won't name names, game engines, but there are a lot of 'em out there. ID at like 30% CPU usage that I absolutely cannot stand if there's nothing being updated on the screen, or if that those updates could be happening on the GPU, then there, there should be no effort being done there. So I will agree with you. The absolute most important thing is to understand your time domains, understand which parts of your apps need to be responsive and which parts don't apply the right technology and all that. But this is where benchmarking and profiling are helpful. I do think. As a mobile app developer have to consider energy usage. And when you plug in, uh, a profiler to your app, your app had better be using zero CPU, the majority of the time or else, uh, people are not gonna want it on their mobile [00:24:42] James: devices. No, I think that's a great point. Um, in general and it, like, I hadn't really even thought about that too much because I'm just like, ah, I'm just writing logic. I'm updating different information. X, Y, Z, and. It's funnily enough that you mentioned this about doing this. I have to, I have to do this for one of my apps, which is also an app that updates a number on the screen, but it's my stream timer. So I actually had somebody right in that says, Hey. Your app is using a little bit too much CPU that I would like, oh yeah. [00:25:15] Frank: Huh. Shouldn't be using any . [00:25:18] James: Well, if you're not running anything, it definitely is running zero. So if you I'm running the app right now, right. And I'm not doing anything and it's sitting at zero. So I think that's [00:25:28] Frank: good. Yeah. I would say zero is always a good number. Mm-hmm [00:25:33] James: if I do start a timer, things are happening. Frank mm-hmm mm-hmm mm-hmm and it does, it does use quite a bit of CPU. [00:25:41] Frank: I don't know what the what's measure. I'm gonna be getting the timer here. We, we can tell if I start hiccuping or something like that. Yeah. Let's see. I'm at 1.4%. 3%. Um, Nope. I'm gonna say this is fine. Yeah. Are you seeing anything higher than 3%? [00:25:58] James: Oh, I'm at like 10% on windows. Oh [00:26:01] Frank: boy. Are you doing a net code? [00:26:03] James: but I'm on a CPU that is also really, really old. So. I don't know or [00:26:09] Frank: count counter, but, but your app doesn't do anything it does. Shouldn't be taking any CPU. It's right. It should be, it should set a timer. And then on the timer, it should go write a file and then go back to sleep. [00:26:23] James: that's what it does. Well, there's a timer that runs. [00:26:25] Frank: I don't know it's running too much. I don't know. I'll have to take a look at the [00:26:29] James: code. It might be, you know, I used to have a different timer that was doing stuff, um, in, in the UI. If I run multiple timers. Yeah. This thing actually does use a lot of CPU. I'm almost have 50. [00:26:39] Frank: I, I I'm gonna agree with your customer without knowing anything more. I'm gonna say yeah. Your timers need some work, James. Yeah. Okay. Well, fine tuning. Well, the next episode, , we'll do some, uh, benchmarking and profiling of your. [00:26:54] James: And that's the area that I really struggle with. Right. Because I can build the app and I've done the things, but it, it goes down to the point, which is like, okay, now at this point, what's the acceptable level of, of it, right? Your acceptable level on your Mac at least. And you're on one, which I haven't run it on. But's like, Hey, this is good. Right. Where mine over here on windows, like, oh, okay. Like I'm probably okay. Over here. , you know, um, this is good. Like I'm, I'm looking at my CPU usage and I, you know, yeah. That's probably fine if I'm, I'm doing other stuff for other people, it's more important. Right. So how do I even figure out how to debug that or. Profile. I think that's a good live stream for us to do together actually. Oh yeah. Probably. I [00:27:38] Frank: I'd try. I'd hope we'd have success. Um, I'll just state general rules of thumb here, though. If your app isn't doing anything, I should be using 0% CPU. I I've come down pretty hard on that. I used to back in the old days, I used to go around to people's windows, computers and clean them out. There's a great tool for it. Uh, CIS internals process. Yep. And yeah, so every windows user should be using that. I wish we had something nearly as good on Mac. Uh, there's a column that's not on there by default. Uh, what you want to put up there is your context, switch Delta. That is the column you wanna look at on windows that is what's eating all your performance on windows. And if you see any app context, Uh, context, switch Delta in which I'm pretty sure your app is gonna come up as mm-hmm , uh, you know, that's a troublemaker. And what that means is your app is getting paged in and out of the process table. So the app is running, going to sleep, running, going to sleep, running, going to sleep. An app should be asleep all the time. Run when the user touches a button or starts editing in a text field or a timer goes off. Yeah. The rest of the time your app should be using zero. So what I do, I, I just keep, um, it's probably not great on windows, but on Mac, I just keep activity monitor up and always in the icon view. And I'm always watching my apps, um, just kind of passively. And when they're running and doing. Good work. I, I allow them to get up to a hundred percent or of 10000% CPU. That's fine if it's doing a job and I want that job to get done, but if I'm not touching the app, it, it had better be darn near zero. Now, in the case of ice circuit, it will never get to zero. Um, even when it's in the background, it's simulating the circuit and that's gonna require some CPU, but you can always just close the circuit or. [00:29:31] James: Yeah, that makes sense. It's like, for me, I'm definitely doing a bunch of stuff and then writing to dis, so it's never gonna be 100% zero, but it should kind of spike to zero pretty frequently because yeah, it should average to zero for zero, zero. Yeah, it should. It's not doing that much. I I'm curious. You're on a, [00:29:50] Frank: sorry, you're on a one second drum beat, right? So your, your CPU should just be that, uh, a one second spike. Yeah. Or an an interval infinitely small spike at a one second interval. [00:30:03] James: Yeah, I think we're at not that so, um, I think that's the, I think that's the, the question I'm also very fascinated to go back in time and figure out, Hey, did, um, Did I ever again, if I was benchmarking getting back to this performance stuff, if I benchmark it, then what happens if I did I increase or did I decrease? Right? Because yeah, back in the day, my application was very, very simple. And what has happened by the way, when I think about these real world things is. I've added a lot of more complexity to this timer. I've added a lot of different switches. I know it sounds silly, but I've added like these switches and this thing and this other thing, you know, and, um, and bookmarking and all this other stuff. Yeah. And calling these calls and that happens like all the time. So the real question becomes, you know, did I, did I introduce something that is. You know, spin and threads, basically, you know, and that's the real question at the end of the. I'm fascinated Frank. I am. [00:31:13] Frank: Yeah. And it's tricky. So, um, we're this far in, but I should probably define my terms a little better. Mm-hmm bench benchmarking. I feel like is when you measure the overall performance of one activity, profiling is when. You measure the sub components of that activity and see how long those are taking so that you can take action and fix things. Hmm. And they have to go hand in hand because the worst kind of performance work to do is when you do a whole bunch of work and then it's not actually any faster, um, or you do a whole bunch of work and you forgot to measure it before you did that work. And you can't tell if it's any faster. So you always do wanna have some kind of benchmark around and. I, I would keep 'em, you know, even if you don't run 'em all the time, even if you don't run 'em in CI, I would create a directory called benchmarks. And if you needed the benchmark once, you're probably gonna need it again, or you're gonna want that project around just to remind yourself of how to write benchmarks and things like that. Uh, so I do recommend getting those in there and measuring, especially if you're about to start any major performance work, you need those measurements. Otherwise you're just fooling yourself. [00:32:22] James: I love it. Funnily enough, Frank and I had a completely different topic for today to talk about. Maybe we'll do a performance V two, cause I do wanna get into some of the crazy stuff, but I will say I do want, I do. I, I like how this went into a real world example of like things that I need to do. So what I wanna do is I wanna come back maybe not next week, but maybe the week after, whenever it is and duke sort of an update on this, but maybe next week, we will also talk about some framework. Performance stuff. Um, our good friend, John peppers just, uh, put out a performance thing. That's where we got on this thing, but mm-hmm I feel like that's a whole nother episode, Frank. [00:33:01] Frank: Somehow we're 32 minutes and yeah, I don't, I don't think we could do it justice, but just, just to leave it dangling out there. So Jonathan peppers, uh, wrote up a bunch, the same app and a whole bunch of platforms as a benchmark. So we can measure roughly the same app. On a whole bunch of different platforms and learn some lessons and all that kind of stuff. So I'd almost consider, he's trying to introduce, or people have begun to introduce a new industrial benchmark and I can't wait to see how it progresses. Yeah. All the community [00:33:33] James: Yeah. So if y'all are interested that let us know good emerge conflict, ATM, hit that contact button. Reach out to us on Twitter. Maybe we'll have peppers on as a guest. We don't have guests on often, but I feel like this one, we might, he would be fun. I think so. Let's do it. I'll I'll reach out to you. all right, folks. I was gonna do it for. Weeks podcast. If you have tips, tricks, recommendations, let us know. We would love that. Reach out to us at Twitter at James Monte Magno at proclaim at merge conflict of M. But. That's gonna do for this week. Of course, we do have a patron bonus subscriber episodes that we put out every single week. We did video format this week. I had terrible audio cause I was on my webcam, uh, microphone instead of my normal microphone. I blame Frank forgot to tell me, but I fixed it. So won't be an issue. But if you're interested in supporting the show further, besides just listening, that's enough support for us. If you want to go further on it, let us know, become a patron subscriber as well as two bucks a month helps a show, helps us pay our fees and keeps us going. Keeps. It's so Frank can sleep at night with his built in tiny little air conditioning unit that he just it's a fan. That's what I'm saying. It's it's fan [00:34:34] Frank: it's a, we AC a, we [00:34:36] James: AC to keep him cool in these hot months. Um, go to me, conflict outta found. There's a Patro button. You can go over. There's a whole much cool stuff there let's go do for this week. So until next time, I'm James, about to Magno. [00:34:47] Frank: And I'm Frank Kruger. Thanks for listening. Thanks.