Performance Engineering: Profiling and Making Apps Fast by Default

0:00Welcome to the Real Python Podcast. This is episode 310. How do you plan for the performance of your Python applications? What does a performance budget and tail? And where should you spend your resources? This week on the show, we speak with Den O Dell about his new book, Fast by Default, Practical Performance Engineering. Den has 25 years of experience in building web systems for companies with hundreds of millions of users. Working on public-facing tools has honed his skills in understanding where performance is vital and in guiding decisions based on data from actual users. Den shares details of his performance framework that works across any platform or stack. We discuss the need for budgeting performance during the planning phase, measuring performance through consistent profiling and keeping systems fast even as your code-based and user-based grow. Alright, let's get started.

1:14The Real Python Podcast is a weekly conversation about using Python in the real world. My name is Christopher Bailey. You're host. Each week, we feature interviews with experts in the community and discussions about the topics, articles and courses about at realpython.com. After the podcast, join us and learn real-world Python skills with a community of experts at realpython.com. Hey, Den, welcome to the show. Hey, Chris, and the thanks for having me. Yeah, I'm excited to talk to you about performance engineering and your book. Thanks. I think we could get this out of the way right away that you're not a Python person. And I think that's totally fine because I feel like these ideas are actually at the heart of a lot of the updates and the work that's happening behind the newest versions of Python. They're working on removing the global interpreter lock and trying to get threads working better and asynchronous stuff has been like the last 10 years. And then most recently, the Justin Timed compiler being hopefully added in the newest versions that are coming out.

2:18So there's a lot of people working on speed inside of Python, let alone the rustification of libraries and things that work inside of Python. I think the stuff that you're going to share, especially with development teams is going to be really great even for Python developers. Yeah, I hope so. Yeah. So I come from like a way background, 25 years in the industry. And so, you know, a lot of my work's been in the browser, Java script, a time script or recently. So yeah, it's been interesting, like writing a book. It's about more general performance engineering when my history has been on the web. But I felt that it kind of needed to go there. Yeah. But you know, being focused just on the front end and everything that happens, you know, after the server layer and into the into the browser and what the user interfaces with, that's all very important and stuff. But software is like, you know, the bigger thing, right? It's like, yeah, it's everything from the core up, it's everything from like the CPU, the way up to the all the way up to the browser and to what users working with. So it's all a big

3:23system that works together and just to focus on one aspect of it, just to focus on the front end, it's great. You solve problems, but that's not the whole system. And if you want to make a software system fast and performant and stuff, you've got to think about it, the whole system. So Python fits into that JavaScript fits into that, you know, lower level stuff as well. And a lot of people building mobile apps and desktop apps as well. So this is all, it's all related, as all this connected together, you know, the world is a big one. Yeah, definitely. Well, I thought we could maybe start a little bit of a background thing like what led you toward thinking about performance engineering, what kind of journey were you on to get to here? Yeah, so it was not something that I was like, oh, I'm going to learn how to be a performance engineer. I'm going to spend my career learning how to focus on this one area. It's something that came out kind of naturally out of being like someone who builds products and user interfaces. And having like I mentioned, having that longer history in

4:25the web world 25 years like browsers, oh, they're still quite slow, but they were really slow back then. Yeah, kind of. E count. A little bit of performance you could from from them back in the day. So, you know, going back not even like 10 years ago, things are pretty pretty dire. So I spent a lot of my time building products and then finding, you know, they don't work as well as want them to. And then having to go back and spend like a whole bunch of time fixing and, you know, adapting and all this kind of stuff. And with the browser world in particular, you've got several browsers you need to support not just one. So, you know, your runtime is several different ones. Just was an interesting challenge here. So I found my time was spend a lot in like all these kind of tweaks to do with performance and trying to make a user interface that's really nice to work with. And that's basically all kind of comes down to performance. A couple of factors as well, obviously design and accessibility and things like that. But performance is like the main one that the thing that when people are like, you know, using a piece of software or website,

5:28Apple, whatever. If it's slow and unresponsive, you know, they're going to give up often not very long. And I'm the same when I'm using science and systems that are slow. I just want to give up and I just want to tear my hair out and never go back to it again. And most of my career trying to make applications that don't make you feel that way. Yeah, yeah. So that's kind of like part of what happened there to get me more focused on performance. I never decided, yeah, performance is my number one focus on my only focus. It's always been like a thread that's run through a thread. But it's always been a thread that's run through like all of my work from, from, you know, 10, 15 years ago onwards. I spend a bit of time at Volvo cars trying to work on some web applications for them that were very like image heavy and really weighing down the browser. So spend a lot of time trying to find ways to improve that, you know, in the front end, but also as I became a team like a tech lead there trying to think about ways where I could make it so that

6:32I didn't have to these things that weren't always like the thing at the end of the project. Yeah. You know, you don't build and then do your performance optimization stage. And there are a lot of people do it that way. And, and you know, that works fine some of the time. But I was finding like over and over again that it wasn't working for me or for the teams that I was trying to lead. So I sat down trying to figure out what all the things that I could do and what I could bring to our way of building software that would mean that we can take some of these things and do them earlier or fit them into our process in a way that meant they weren't all at the end. And we weren't suddenly discovering like after we launched something that something slow or suddenly discovering a week before launch that things are slow and that final week is like just this dress ball of trying to eke out all the little performance tweaks we could from something that was probably architected wrong from the beginning. You know, try to work these things back into the process so that next time we run a project, how could we do it differently? And that's kind of where

7:32this whole like idea of what I call fast by default came from is trying to take all the things that we can that we would otherwise be doing at the end and feed them into the process earlier on. And a lot of that's about like training developers to build things in a certain way that anybody won't deal with before spending more time thinking about architecture at the beginning than then kind of seeing how it goes as you're building. That's funny. And yeah, I have an analogy. Oh yeah, great. Yeah, and the world of cooking, you know, and chefs and stuff like that, you need to start with good ingredients. And I feel like architecturally, if someone's just using what they're familiar with or using what they've used in the past, or maybe what's been, well, this is all I can get. And it's not a great starting point that you're kind of starting behind. You start with great ingredients, your food's going to just like be elevated right away. And I think

8:35your career has shifted a little bit in the sense that you've moved away from the specifics of this sort of stuff. And as you become like a team leader, moving to management types of stuff, you have to distill like practices like, well, this is how I would find that this is a good tool. Or, you know, I don't know if I need to say it's like, you know, because I tried to do JavaScript for a while. I still mess with it off and on. But it was very dizzying 10 years ago to try to stay up with whatever was happening. There was like seven different ways you could control your CSS stuff. And I was like, okay, do I do go up, grunt, sass? What do I do here? I could stand up. I'm pleased to report there are now about 25 different ways to do the same thing. There are just more options. But there's more options is better because you can find the one that better fits your use case. But yeah, it's hard to stay on top of things in the web world in that way.

9:40Yeah. And the new in shiny, there's something new in shiny every week. And, you know, the temptation is to just reach for that because that says it's going to solve this problem or, hey, you've got performance problems, we've got this tool for you. Why don't you try this out? I'm sure it'll be perfect. And, you know, the thing is that, you know, the new in shiny isn't always better. In fact, sometimes the really old stuff, the really older technology is the stuff that works the best because it's been refined over so many generations and years and stuff that, that that's the stuff to rely on more. But, you know, ultimately, there's only a certain amount of stuff you can do in the browser. And I'm sure it's the same on the back end and mobile apps as well. Yeah, they keep adding new features and stuff, but ultimately, the core stuff is the same, you know, the networking layer and the rendering. There's improvements that they make, but ultimately, these are the layers that exist. And in order to improve performance, you know, the new features here and there and someone will come up with a great library or someone will come

10:41up with a new framework that is good or better than before. A lot of the time is that the new framework is less about improving performance and more about improving developer experience and making it easier to write apps in the first place. And that's absolutely got its place for sure. Yeah, frameworks and libraries, you know, these are adding extra layers on top of layers that already exist. And if you can strip it back and get back to whatever the core level is for the browser, that's just plain CSS and plain JavaScript. If you can write in that, things will definitely be faster than using a framework. But, you know, there's other benefits that come with frameworks as well. That's been your experience. Absolutely. A hundred percent. I've tried a lot of different frameworks over the years. And the more you strip back, the better for the experience. Now, developer experience is a different matter. You can argue that perhaps that's, you know, with the LLM's coding agents that we have like, claw codes and whatever, helping us to develop,

11:42that maybe it isn't as important with developer experience because you've got someone else doing the work for you. So, you know, that's very interesting. It's also interesting that just on the side that will react is one of the frameworks that's very popular on the web. It's been around for more than 10 years, probably as something like that. Very popular. Most people train and react, they're not really training JavaScript anymore. They just learn how to do React and build React apps. They move up to the higher level. Yeah, exactly. They go up to level. And so because there's so many tutorials and so much information about React out there, then the agents learn from that and they think that that's more, it's better to use that than it is to use like core JavaScript, whatever. Whereas they could use core JavaScript, all the information is out there. They've learned it. They know how, but they optimize for the framework because all the information out there is about the framework. And often if you're coming in and you write your first prompt, you say, hey, here's the stack I want to use. It's React. And I want to

12:43use this library and that library. But if you can strip it back and just say, hey, I want to use anything, stop you with the basics. And if I need to add something later, then let's add it on. But the less the better. Yeah, I was thinking about that. I've heard other practitioners working with LMS in the Python space doing something similar. Like, oh, don't, try to have it right at the lowest level possible in some cases. In other cases, again, we already talked about performance potential issues here that there may be other tools that could potentially speed it up or whatever. I just remember somebody recently saying, well, I had it just right instead of having an object relational mapper, an ORM kind of system, I had it just right. The core SQL stuff and so forth. And it had a bit of a performance boost, but at the end of the day, he was still having a hard time understanding the code after out of it. So there's going to be a balance there. Yeah. It's going to be a balance. Yeah. Because he's not going to say, hey,

13:45just right, everything in assembly and have done with it. Sure, that's the best. Most performant way of doing it. But we are all humans trying to understand the code that's being written. And we're ultimately responsible for what's going out there and getting released. And we have to do the code reviews. And we have that responsibility of something breaks with the ones who have to fix it. And if it's just byte code or if it's something, if it's a low level SQL that we just can't follow without having that ORM lap on top, then it's going to be a struggle. Yeah. So my experience is it's good to have some layers in there. So you don't just go down to the lowest possible layer, but the fewer the better. Adding them for reason, having that reason to add them because we want to understand it better. That's a valid reason. And the straight-offs with everything. You already mentioned some of the background on all the new frameworks coming in. But as a technical lead, were you seeing engineers stacking lots and lots of libraries? And 100%

14:50was that a difficult conversation to say, hey, there might be performance issues here? Yeah, no, 100%. I mean, it's very easy to find a library to have a problem to solve and just do a search and say, hey, is there something to solve this problem already? And 90% of the time, there is something to solve the problem already. And so you think, hey, we're just import this and use this. And great, so my problem, you know, I delivered a feature in one week that probably were taking me four weeks to spend the time written it myself. So that's valid. That's saving time. Companies love that you save time and money. But ultimately, some of those libraries would be great and would be absolutely fine to use. And some of them just won't at all. And it's having the time to look through the libraries and investigate what it is that they're actually working, you know, have a solving the problems. Yeah. And then finding out, you know, what they're actually doing, what, you know, the way that they're working is it's something that's not very

15:50performant or is it something that's, you know, had I written it myself, this is probably the way I would have done it in the best way. And that education amongst the team is very, like, very important and having people understand that not to just choose something because it solves the problem, but to understand how it's solving the problem. And, you know, and thinking for yourself, like, objectively, is this the best way? Are there other options, other options out there that are lighter, you know, that don't take up as much. And JavaScript, well, when you ship a new library into the front end, it's quite a lot of extra data, your bundle size, your JavaScript file gets bigger and bigger. And, you know, that everything kind of waits for that JavaScript to download and pass before you get the experience. So ultimately, you're having a knock on effect on the rendering time as well. So that's something that, you know, you want to affect. And you can move stuff to the third side and that's great and do as much as you can there and send less to the, less to the client to render in the browser. And that's good. But, you know, you're just offloading one problem onto

16:52another and you know, you just moving it around. Ultimately, you should just, the other way, is a better way of solving this problem. It could have done it myself or that stripped it down to the bare bones. So just what is it we're trying to solve and just solve that problem instead of, you know, a bigger picture because most libraries, they, the longer they're around, the more features they add and, you know, the more people have raised issues about this case in that case, they aren't, aren't you particularly use case, but, you know, solve added problems for some people. And, you know, obviously as a library maintainer, you wouldn't be able to support as many people as possible. So you, you know, incorporate all of these extra PRs into your solution and some of it has code that you won't run or ever come across. So, you know, unless you've got something that strips out everything that isn't being used, you're going to have to think very carefully about what it is that, you know, the code's doing and, and, you know, just take the bits you want. Yeah. I think we'll talk about this more, but I feel like when that engineer

17:52adds that library and has added that feature, are they in the practice of then testing the performance after that? Well, that's the thing, and that's the thing that I've been trying to teach as well, this whole idea of, yeah, you know, how do you know when something is, is on performance? Well, you know, how do I know that I've introduced the performance impression? And when I've added this library, ultimately it comes down to like having thought about an advance about what your kind of performance goal is. So, like what is that the business uses down to the business? Like, well, the business is trying to achieve with whatever features I'm trying to do. So, they are doing building a checkout API or something. And, you know, this is something that people buy something online and they go through a checkout API right at the end. And the performance of that is going to affect how customers feel about the experience of buying on a website or Apple, whatever. And potentially abandoning it, apparently, which I have done. And saying here,

18:56absolutely. So, you know, that business might say, okay, that checkout API mustn't take any longer than 500 milliseconds, for example, because anything longer, it's going to be a noticeable effect to the user. And, you know, that's going to have negative people reflect negatively on the business. So, you know, there's a goal right there. And from there, you can take that and create a performance budget. So, very similar kind of thing is essentially the goal, but with a little bit of headroom in it to allow for you to, you know, occasionally go over the budget a little bit and kind of just hover around that point. So, say it was 500 milliseconds and you want to aim for like 450 or something with what you've got. So, you've got to do obviously measurement of how long your endpoint is taking. And you can do this in development. You can do this in production as well. Absolutely keep that information in your logs and stuff so you can feed that back into the into the system. So, sticking to a budget and when I add a library to that API endpoint or I want to,

19:57you know, add a new payment provider into that, for example. And that new payment provider is slower than the others. And it has an impact on performance. You know, what would I do at that point, you know, that's a great my budget and the ultimate business goals can get broken at that point. Do I go back to the supplier of that payment endpoint and work with them or make it faster? Do I try and, you know, account for it in hours and try and make tweaks to hours? And there's only, you know, a certain amount you can do. So, yeah, having the ability, I think, to occasionally break the budget, was that raised up to, you know, management and that they understand that we're going to try and fix this problem, but we want to release this feature. So, you know, having this kind of like, we've had the headroom beneath the goal, have a kind of headroom above there as well that says, you know, occasionally we're going to allow ourselves to go over, okay, as long as, you know, these things have to happen straight after. So, the things that need to be flattened and they need to be documented and we need to plan into, you know, sprint, you know,

20:59the next sprint or the sprint after that that we're going to deal with this, you know, within, you know, this amount of time and we're going to get it back within that headroom at that point. And, you know, document the things that need to happen for that goal to be then reached again. So, I need to reach out to this, you know, payment provider and work, for example, a better solution, or we need to implement better caching or something like that that, that, that, um, they get to you back down beneath that line. So, yeah, it's all about having like goals and budgets, but not getting to the point where there are so prescriptive that you refuse to allow new features to go out because one might slightly break, right, you know, slightly go over the line. Obviously, I get the case where things go drastically over the line and you need to think of something completely different to do. I had a case, we had a case where actually working with a payment provider and it was one of those payment provider systems that, that they use in, in like stores and stuff. So, you know, if you're sitting down at a bank, for example, and they're saying, you know, I want to take out a loan, they've got a computer system where you type

21:59in the numbers and then they press the button and then you're sitting there waiting for like 10, 20 seconds for an answer to come back from the system with like, you know, a price for your loan or whatever. Yeah. So, we were trying to integrate a system like that into an online checkout system where we could get a updated price before, you know, as people making changes on the, on the website, we wanted to update the price, but each time we were making changes, it was taking 20 seconds to get a new reply from this system. So, it was not a very good experience at all. So, we needed to obviously document like what the problem was that, you know, obviously went way over our budget at a time. How long were we going to be able to live with it before, before we ultimately fix the problem? So, in the case of that problem, we knew we were going to be able to cash the data, we just didn't have the resources available on the team enough team members to be able to build the cashing system to preemptively select like the most common options and stuff and on the system to be able to cash them on our side. So, yeah, we knew that that was going to happen, but that would be

23:02like two months down the line or something. So, in the meantime, we had to make changes to the, to the user experience to try and like mitigate the effect on the user a little bit. Yeah, we know they wouldn't be able to get the price immediately, but maybe they'll be able to get some other information and stuff to it. So, they're making changes. We can make sure that the UI updates, you know, in real time so that that feels as if it's responsive and you know, have a little skeleton load or a loading spinner for the price as a kind of temporary measure before we resolve the main issue. So, you knew there was activity there, the customer could say, okay, I can see there's something moving here. Exactly. So, they could see, you know, they weren't feeling like they were dragging sliders and suddenly they had to wait 20 seconds for the price to come back before they just started dragging it again. They knew they could drag around and you know, if they started making new selections, we could cancel old like requests made to the server to get the, get the prices and just deal with the most recent one. Yeah. And yeah, a lot of things are about, you know, perceived performance and about trying to make the experiences as feel as smooth as

24:03possible even if underlying that is something a lot slower. So, yeah, we had a crazy problem with that, but you know, ultimately we fixed the problem, it's really smooth now and yeah, it's just documenting it, knowing when it's going to happen, escalate into the business that we know this is a problem. It's because of this. It's not because we had developers or anything like that, but this problem will be fixed in X amount of time and we'll get back there. Yeah. Maybe we can start with sort of defining fast by default. Also, we should probably mention that you have a book. I don't know if we even got there yet. That is literally titled fast by default practical performance engineering. It's on Manning and currently available in the Manning Early Access program, which I've talked about before on the show. So, people are interested in love links for that stuff, which came first was the title there first was your ideas around that or was it developed as you started writing? No, the ideas and the title, I guess, well, the ideas came first. So, that was just me making a whole bunch of notes and documenting things as

25:08real performance issues came up. It was clients that I worked on over the last 15 years or something. I came to the point where I thought, I've got a lot of these notes. What should I do with them? It feels like it's a waste to just have them sitting there on my hard drive and not share them with the world. I'm just writing a whole bunch of blog posts or what do I do? What should I do with this? It feels like it's a shame to waste because I can see other people having performance problems and they're not adopting these techniques. So, what should I do with it? So, I thought, I think I want to write a book, I've written two books before years ago on JavaScript. So, I knew I had it in me to do it. I kind of studied like structuring something together, like how might one kind of teach all these different things in what order and how to kind of define it in a way that is kind of like framework that's one kind of thing. The name came all the way at the end of that fast by default. It came about because of things

26:13like resilience by default and all these other by defaults that there are in the world of the techniques to improve various different aspects of software development and user experience. And I looked around and I was like, why is there nothing for performance specifically? That seems like a bit of an oversight. I certainly would have really appreciated having that knowledge written down but the time I was experiencing all these issues. So, yeah, I thought it's called a fast by default and then just see what happens. So, I pitched it to Manning. And the original idea was it was going to be a web performance book because obviously, when we talked about web, it's my history and have written books on JavaScript before. I thought this is a great area where I can write a performance specific performance book on. The Knicks and Crannies of exact places where these things happen. Yeah, yeah, yeah. But then I realized I haven't actually teaching something that's more

27:13kind of like general than just web. When I'm talking about performance goals and budgets, that's not something that's just unique to the web world. Any kind of software development, and that's performance that they release to anything. And when I was going to write about like profiling, that's obviously not just something in the web world. It's something reasonably new in the web world. Like people, right? I want to talk to you about that too. I'm familiar with the Python ones because again, I've been watching a lot of people focusing on this. In fact, they're adding a very elaborate one in 315. It even has a name. I get remember its name right now. They're really thinking about it. And I thought about like, like, flame graphs and where memory goes and things that try to keep the profiler from causing a bloat of itself inside there and like, was it looking at and being able to identify where the problems are. I would guess there would be a similar growth in quality, hopefully, of these tools.

28:16Is that your experience in the web world? Absolutely. Yeah. Definitely. And I have to say credit to Google for Chrome because they've added a lot of tools into this development tools bar that you can get at the bottom of your browser. So there's like a developer menu hidden within Chrome. And if you enable it, you get this whole half of the screen at the bottom. It just focus on development tools. And the whole section of it is to do with performance. And like you're saying with flame graphs, it maps the JavaScript usage and memory usage. We talk about DOM nodes a lot in the front end. These are individual elements that's on the page, basically, so a title or an image or something like that. Each one has a DOM node and it keeps track of where how many DOM nodes you have, the more DOM nodes, the less, you know, the faster experiences in the browser because it's had to keep track of all the DOM nodes. And you know, whether those DOM nodes stick around after they shouldn't do so we have garbage collection in JavaScript. And but if there's like a reference that

29:17hasn't been closed properly to a DOM node or something, then that DOM node stays in memory. And if you're running like a long web application that isn't designed to be closed down, then you know, you keep it up for hours. Then then those things accumulate over time and you end up with a slow or thorough experience as you go, yeah, if you've ever used like, well, Facebook, Slack, things like this in the browser and you probably keep them up for a long time. You know, those teams have had to focus a lot of time on performance, for exactly that reason, and freeing up memory and tracking what's being used and event listeners in the browser, how they have come to elements and repeated things on time as sometimes if the thread gets blocked and sometimes happened at the same time as each other and conflict and things like this. And so these these developer tools in Chrome and they have them in Safari and Firefox as advanced as ones in Chrome, but they are pretty good in getting better. So these allow you to profile code and see exactly where things are going wrong and you can really drill down on what functions

30:21have been called and how often loops are running and which elements and browser we've been hooked on to for too long and things like that. So yeah, the tools are there, but I found that no people don't know how to use them because they are. Yeah, you know, these are new issues, sure new at least in terms of the level of granularity where it was go down to now. And people don't know this and because there's that learning curve, you know, I'm I wanted to kind of teach that in my book and as I work with people as well about that and obviously profiling, you know, the same ideas of flame graphs and memory usage there across everything, you know, I've been doing a little bit of development, iOS development as well. And you know, similar tools exist there for you know, for creating flame graphs and tracking memory usage and things like that. And you know, why not use them? So and why not use them while you're developing instead of waiting until, you know, you're on your staging server or you're later on in the process and you finally realize, I've you know, I've got memory usage is scaling up and I had no idea why and I don't know what's

31:26going on. You mentioned in a couple different places, this idea of profiling and you kind of have it as a daily task, which I thought was really fascinating. But if you were to introduce something in a particular day and then profile it, you are like being like a week or two weeks away from like realizing, well, where did that happen? Like you, you know, it is within this time period of this chunk of code, this diff, if you will, where this has happened. Is that part of the reason for wanting to profile daily? It is absolutely yeah. And so, you know, when I say daily, I don't necessarily mean, you know, yeah, I understand that I get I get that yeah, yeah, exactly. But while you're working on something specific and ideally small, to profile at the end of that or, you know, while it's going on is is ideal and to get as much information as you can while you're developing is really the goal there. And yeah, it's all about measure measure as you go. Absolutely. Yeah. And that's the main

32:30thing about performance, isn't it measuring and you know, measuring that you have a performance problem. A lot of people I hear come to me and say, my my side is really slow and I'm like, okay, is it is it slow? Do you know that for sure? Let's say they say it feels slow. People can be in their feels slow, but until you measured, do you actually know that it's slow? You know, there could be something. It's some other factor like their machine or the network or something like that. So, you know, measurement is the key thing and that's really the thing with profiling, isn't it? It's just measurement, but at that really granular level of where the code is that you're writing at the time. And yeah, it is all about feeding that back earlier because the hardest thing I find in focusing on performance in code is leaving things too late that you can't go back and easily fix it because once you've added, you know, one feature, another feature and re-architected a rewritten some parts of the code and then you find out that there's a performance problem going back to that first feature and making a change that other things are then built on top. It's hugely

33:32disruptive or can be hugely disruptive depending on the size of it. To both sides of the situation there, if customers like the feature or have gotten used to it and if the developers have a hard time like being able to wrangle that. Absolutely. And one thing that I found for being a team lead as well is the developers really don't like it when what they have to do in a sprint is just focus on performance fixes and treats and bug fixing and things like not that, you know, not everyone is interested in the formuses. Exactly. It's not and you know, it's treated like it's a bug and it is a bug and those are way less interesting than working on features. And you know, from business and engineering managers, they do dislike it as well because, you know, I'm not spending two weeks working on fixing a whole bunch of bugs that should have been right for the beginning instead of building this new feature that's supposed to be launched next month or whatever. So yeah, that whole idea of doing it as you go along, the four things get built on top of it and it becomes

34:38even harder to work through. That's really the whole reason for doing it daily or as frequently as you can. So yeah, profanely is super important. Yeah. And yeah, and like having the habit of doing it, I think is, you know, I think some teams are better at it than others and some, you know, I think in the back of the world, it's something that's been around for a lot longer than it has in the front end world. So it's, you know, more ingrained into the way that development works then. Maybe you can tell me more about your experience there than I know, but that's the way I certainly say it. Yeah. Yeah. Yeah. I think the architecture part that you stress and that totally depends on where you're at and so forth if you're literally standing something up is such a crucial part of what you're kind of saying, like thinking about all the stuff in advance. And I think, I think the default word is a really good word across the board here, like this idea of like, you aren't against the idea of prototyping. We had a conversation on the show a little while ago

35:38from somebody else's article was that there are traps. And in some cases that if you build a prototype and then someone in a higher management gets a chance to play with it, they think that you're done. And it's like, no, no, no, no, no, this is just to show you functionality and to kind of get, like, start a conversation and make sure that we're going in a going to head in a correct direction. It's like, you know, laying out a, you know, the storyboards for a movie. It's like, well, we're not going to shoot pictures of the storyboards for the film. This is to get the idea and find mistakes and find that if this is a right direction. But we're going to have to go back and literally build a set and shoot this thing. And I feel like that's kind of a weird trap that people then try to use that code. And it's like, no, no, we need to kind of, and so it's like waking people up to those ideas. It's time to shine a spotlight on another Real Python video course.

36:41Do you want to optimize the performance of your Python program to make it run faster or consume less memory? This course is titled Profiling Performance in Python. It's based on a Real Python tutorial by Bartosz Giacinski. And the video course is presented by Nagar Vahid. This course digs into several areas of advice before diving into any performance tunings. Why should you consider software profiling determining if the effort to refactor will take longer to improve the code than the amount of times you'll run it using a profiler to learn where your program consumes memory and ways to make it more efficient. And how do you several Python tools to measure the performance of your code, including time it, see profile, p stats, and pi instrument. As a precursor to checking out the video course, here's a short checklist to figure out whether you need to work on performance. Testing, have you tested your code to prove that it works as expected and without errors? Refactoring, does your code need some cleanup to become more maintainable and pathonic?

37:45And then profiling, have you identified the most inefficient parts of your code? Like most of the video courses on Real Python, this course is broken into easily consumable sections and where needed you get code examples for the technique shown. All lessons have a transcript, including closed captions. Check out the video course you can find a link in the show notes, or you can find it using this search tool on realpithon.com. You have lots of these lists and I think they're kind of interesting. Like you have a system is fast by default when and then you have like a list of these things and there's a you have a website fastbydefault.com all together as one big word. A lot of these ideas are there so if you want to revisit them and think about them, I think they're pretty good. I don't know, would you like to kind of go through some of them? Like some of these like core ideas, like we're kind of just kind of touching on them, but like where do you feel like is a good place for people to kind of start? You have like seven principles, where do you want to dig into?

38:50Yeah, I don't mean it's it's hoping you know if you go to the site, it's like a big list of things. That's a lot of stuff. Yeah, and then you're like okay, what do I actually start? And that's why it's kind of good with the book because you know you read it from beginning to end and you know I go into detail on each of the things here. Yeah. You know like kind of I have it in a kind of like rough order anyway. It's funny because I have a lot of people write these books where they'll literally say you can read this in whatever order that you want and I kind of feel that as much here. I mean you could come back to it in that way, but in some ways you want to introduce people to a new methodology to start with this in mind. And then these are the things that kind of flower out of it, but like there is kind of a core introduction to the concepts. Exactly. Yeah. So in the book, the first few chapters, I think probably the first four chapters really are talking about concepts and the idea, the framework and how to you know what performance,

39:53why performance is important? That's like the first chapter. And the second one is all about you know how to convince your boss and their boss and their boss is boss that is important to focus on performance. Which I think is really important because you know you can be like the most you know passionate person about performance and say we need to make this fast through whatever. But unless you're talking the kind of language that the VP understands, then they're not going to say yeah let's dedicate some time and some budget to doing this. So you have to talk in terms of like how much is going to cost them if we don't do this and how much ROI or whatever. Wow, that's really important. Yeah, they talk about that all the time and that is really important. And you know losing customers is pretty much the big one when it comes to performance and like we're talking about and you know slow experiences, they degrade your trust in the system as a customer and you know that means a lost customer. And you know there's some things about performance like you really come

40:54to like mobile apps you have to download them, the whole mobile app to your device before you use it. Yes. And you know if you don't have to space on your device then you don't download it. But as a business you don't know that someone didn't download your app because you only have the statistics about when people did download your app. So you know you have to do a little bit of research and stuff as well and like compare against competition like you know these competitors has you know 50% smaller bundle size on their app and so you know that's we think that's why that they have you know extra more customers than we do for example. So you know freely in terms of trust and in terms of how much time that customers are going to get back versus the time it's going to spend to do the development work and you know ultimately how much money they're going to make. That's you know that's the big one. Yeah yeah. And so framing in terms of those languages so you know before we get to talk about any like you know how to actually profile your code or things like this you know this is all really important stuff and so Yeah it's a big conversation I can see yeah we are all the different angles of potential pushback

41:59you know from all parties. Yeah absolutely yeah so it is really important and so it's important to to put a flag in the ground is going to be hard here. Yeah absolutely yeah so that's like a really key like focus that won't be with unstan before we get into the nitty gritty of the code stuff. And then you know when we talk about performance goals that we were talking about that comes partially from the business and partially from the team as well about what they think that you know what is what is good enough when it comes to performance of what you're building. Yeah you know how to document that and how to get a number and not just arbitrarily pick you know I won this year's one this year's one. Yeah I've never heard of it as a budget a performance budget that is a really interesting idea that like where is it acceptable here like initial load okay this is somewhat acceptable versus like a payment screen like this that's got to be tight and not stopping somebody and having them have a second thought potentially if I mean that maybe that's a dark pattern I don't know but I feel like as long as it's where the areas need to be smooth and where stuff needs

43:05to be sanded and and yeah I think that budgeting is really interesting. Yeah and it's it's really key to keep your own track later on so that's why it's so important to understand it and to define that stuff early on before you start optimizing your code because you know you need to have something to optimize against and a measurement that you're comparing against every time right so right you know so that the work you're doing is deterministic and you know if it meets that goal then it succeeds and if it doesn't then you know conversations need to be had and so part of that fits into like understanding this concept of critical paths and you know critical and that is essentially like broken down into what the user needs to do and how long is acceptable for them to take to do it and that could be a long flow where they're like you know browsing a site for buying some clothes or whatever and then you know taking them through to the checkout and you know how long is acceptable for the whole process end to end and you know what you need to do to optimize that process and most of the optimization will usually be towards the end but you want to make sure that you don't

44:06lose people on the way if it's a flow so in terms of the web that's the critical path there and critical path on the backend is you know all the different systems that are connected together the database and the network layer and you know if you're jumping between some system to system you know how those systems are connected and how how close they are to each other yeah so you know that's the idea of a critical path there so the same kind of concept applies across a lot of it and then after that we talk I start talking about architecture and about you know what the best kind of ways of writing your apps and you know whether it's better with monoliths and microservices and things like that and how to how to structure things then I start talking about turning those goals we talked about earlier into the fixed budgets with the headroom on either side and then I start talking about profiling and then I start talking about build sizes and you know how much time issues are taking the like runtime issues for example like how long things are taking and how to find that out earlier on and how to surface that

45:11information to developers while they're developing and not later on yeah so as another is a very like key point across the whole book is to try to get the information to developers as soon as possible so that you know we don't have these problems later on so then that naturally feeds into like code review and and then like testing and feeding testing back from the real world into the into your application and into your team as well and and then about automation the CICD and how you make sure that all the things that we've been teaching up to this point are gated so that you know things don't go out that break automation checks so say you forget to profile one feature and it makes it waste it's way through and you know it gets caught before it goes out and then you know things happen after that like over time just stack my change you might add like we're talking about extra libraries and things and how to make sure that your application can stay perform and are requesting exactly exactly you're not regressing and how to review those things in the in the

46:14you know the idea of performance before you implement them into your into your system like one of the chapters later on is is all about like team culture and about how performance is not a development problem it's a team problem and it's an application problem and it's communication problem it's a communication problem exactly yeah and that everybody's involved you know even a designer the test is the the business folks the product managers and things like that everybody it's on the same page when it comes to performance and everybody knows that it's important and everybody knows that this is something that we have to keep you know on a on a keel a level keel otherwise you know things are going to be bad for the business later on and bad for us as as team members as well yeah and then and then the end of very under the book because I know a lot of people when I come to the book and say I've got a problem how do I solve it so that the last few chapters of the book are very specific kind of like as a cookbook kind of thing this recipes in there about you know I've got this problem how can I solve it basically and then that's like like a bit of a flow chart like where to look

47:17exactly yeah exactly specific code as well the bad way in the good way and these these kind of things and so okay compare yeah exactly and so that's like the kind of thing into end to end and you know I think it it flows because it's talking about you know what's important at each stage and yeah development is a massive chunk of that in the middle but that's not the only thing just having that awareness from a team perspective and from a company perspective about what's important I think it's like that's the key thing having everyone on board because otherwise you'll end up with someone me going into your your application and being the one to fix all your performance problems then going and then you know you end up in the same situation again six miles down the line it's going to be something everybody owns it's going to be something everybody sees as important otherwise you know it's it's not it's not only the fast by default it's fast for a short time until the next thing comes up right you mentioned we talked a lot about you know check out

48:23windows and things like that and web performance and so forth but you have a example I think it's maybe the first chapter we're talking a little bit about Slack and they had a problem with like just like you're trying to type and it's taking a half a second for like a letter to appear and that yeah you're just like I'm going to close the window because this is like yeah frustrating to to no end so it can be those pain points may not be obvious to a developer beyond systematic testing of like you know unit testing and things like that I'm guessing there are other you know QA types of steps that are in that that are again part of that communication cycle of like saying you know how did we get here yeah exactly and that's the all a part of so yeah there's the QA phase as well the real testing you know but there's also the the actual real world testing which is everybody in the whole world using your application and you know feeding that information back through your logs or whatever reporting system that

49:24you have so you know about it so you can measure you know input latency and things like that and for that kind of application having a performance budget that's specifically about input latency is it's very important you know because that's that's one of the key things you know when the user is actually interacting with your application it's that immediate response time that's so important like I think it's it's about 200 milliseconds is about the response time that anything below that people feel like yeah the system is really responsive and anything over that is starts to raise questions in people's minds like is this slow is it just me and you know once you get past 300 milliseconds to 400 milliseconds then people are like it's a noticeable difference and especially if you're on a type you know you type fast and if you're waiting for that cursor to follow you along the screen like that's just an absolute agony when you're someone who's is writing one day especially an application like that where where it's all about chat so you know those stack fixed that problem you know once they realized they got the feedback from users and then they started

50:27tracking input latency themselves and so the great deal system around it as well does something that I've tried to fit throughout the book is small case studies like this where church teams have done teams have had this problem and dealt with it and the way that they've done it because everybody fixes problems in slightly different ways so sometimes it's useful just to see you know how slacks of the problem will shockify so the problem with them with their API and you know all these other teams that are out there who have had all these problems before and like learning from them in the context of while we're learning about you know why performance goals are important you know what performance goals you know these other teams have what you know what on Netflix has for example and how that helps the development team work and sometimes they're like anti-case studies I'm not sure if you saw the the ones about monoliths versus microservices but you know I was going to ask you like what in the end like yeah I've kind of lived through that conversation but I

51:30I feel like things have rotated back to more monolithic type of stuff partly because of I think it's partly a bit of a reliability thing but also just like it could be just literally a speed performance kind of thing and then maintainability and so forth but I don't know what you're experienced you've been way more out there and the trenches than I have sitting on the sidelines here watching well the thing is both work and it just it really depends on like some architecture decisions but it just yeah it's a system thing obviously you know microservices were split in the system up so there's always that small communication pain with every connection between every other system and so you know there's there's always that small chance that one system is installed in our pool you know this you know we're going to have to use a load balancer to switch between and then that's going to add a little bit of extra time for that one little microservice connection the latency is adding up exactly the latency is adding up and you know you don't get that obviously

52:30in the bottom monolith system but then you also get the problem as if monolith goes down then everything's down then monolith goes down yeah exactly so and you can't work on the individual components as maybe easily or no exactly so there isn't one solution that's best and there's one solution that's the one one that isn't yeah I've seen you know a few years ago everybody went down the microservices route I've seen more people go back to the monolith route recently but equally I've seen so many people on microservices were working really well for them and they had the kind of system that is ideal for that so yeah there there is no one right answer and I try and present that in the book as well and say you know this is these are the trade-offs between the two and you know which trade-offs are the ones that match your system because those are the ones the ultimately choose which which route to go down and are these useful having like I think I'm the example of the Amazon where they chose they chose to take them on a listen split into microservices and it ended up disastrously and everything you know it performances way worse afterwards

53:30they suffered from a latent latency effect and they went back to the monolith and you know just made tweets and changes sort of way that they were accessing their data and and organizing things within that that improved performance for them you know it's not always that there's so much harder to do late this kind of the key like theme I think you're presenting in the book absolutely yeah yeah that's it's it's it's painful at the end so make it less painful throughout yeah yeah you have these question error I kind of wanted to maybe kind of quickly go through them and then I thought about like some follow up for them you have this do you catch performance problems during development rather than after release and I think that's we've kind of touched on that a whole bunch our performance budget's defined and enforced automatically in CI so that that's really interesting so like you're saying that there is going to be a test that is part of the integration step am I reading that right then that's right yeah so we're going to run as much as we can as

54:34simulation of the production environment in CI and we're going to make sure that we're going to do the measurements there on a kind of realistic simulation of the machine just going to run on and you know within okay within financial constraints and how much you can run you know every time on a pull request but yeah we're basically going to discover that information at that stage as well as developers doing it throughout and obviously there's a tendency that developers get lazy and they just leave it to the automation stage to catch but then you get the problem where things are more painful to fix afterwards so yeah so and something that kind of some we related to that is what we're talking about budgets and like I try and have like a PR template that are used where you you report what the the metrics are you've been measuring and profiling locally and you present it in that so to kind of prove to the other team members that you have been doing that work yeah and the these are the before and after numbers and they think they could go up and down or whatever they

55:38whatever they do but just to show that you've been doing it and you know that acts as another kind of you know another gate before we get to the automation part of it so I think that's that's really important yeah but yeah basically simulation yeah yeah I think that kind of goes to this next a question coming coming up with the do you do all foresee the performance impact of their changes as they work which is kind of what you're saying there like the profiling locally if you will and looking at that performance there yeah and this and there's another thing with that as well profiling is brilliant but for some systems especially visual ones like the web like apps sometimes it's important for developers to see in real time within that app what the performance impact is on the changes so you can measure things like frame rate and things like that within the browser yeah any video game person would be very familiar with yeah sort of performance stuff right away yeah absolutely that's exactly where the idea came from so in some of the later chapters I talk about having like a you know heads up display on your on your application so that you can

56:43see you know at a glance as you're using it what performance is like and you can see like red you know red flags coming up okay we're already here's input latency over here here exactly here's redraw or what have you yeah okay yeah exactly and so that's that's really good because you know the stuff you don't catch in code you can catch when you're doing testing and testers can bring up this same display as well on them on their machines too and and just kind of front brake system and see where where the points where you know latency gets too long or the points where the frame rate drops sufficiently that it's affecting the experience and those will then you know feed you into looking at the the flame graphs and seeing what's happening at that point where those happen and and digging down and profiling then yeah and the last thing I have is like do you run regular cleanup cycle that removes the dead code and unnecessary complexity and we've talked about this before like this is one of these big big big steps of becoming a professional like

57:43you developing code you know on your own and you move this idea of working with the team but then this idea of like owning the code making sure that it's extensible it can be expanded upon and can grow but then also like are you regularly like pruning it and you know keeping care of it yeah I think that's a really interesting step and it made me think about this idea of like okay what are the areas out of the stuff that we talked about you touched it a little bit but like where do you get pushback on this stuff yeah yeah pushback does come and it's usually in terms of how long things are taking okay because you know adding in profiling into development excuse me means that you're not delivering x-feature to to the server you know within the same amount of time but it would have done if you hadn't been done profiling and so yeah pushback can come at that stage you know the question to start coming in about how long it's taking that I think it never to be leads to is this even important to do and going back to that exact same question we had like early on in

58:44the book is it important to focus on that because you know some people in the business will say it's more important that we get this feature out because this feature helps us sell more whatever it's the same right there's going to be a headline on the website you know this we have this yeah so this is like this is something major we just want to get it out there and get it get it working and you're saying oh I can't do it because I need to spend you know I need to spend the you know the next four hours profiling something that I built and I don't know you know if I'm going to have to then feedback you know do some more work on it before it's it's good enough so pushback does come then I try and refer them back to the that original discussion about you know ultimately the this is offsetting more pain later yeah so this is you know this is more about yeah taking those little hits rather than the the big one later on that's hard to get people to think about the future yeah exactly always this yeah but you know in terms of that budget and allowing yourself to go over as long as there's a plan

59:45to go back under again later and to say okay well you know if we're going to give up on this now because we have to get this out this week then these are the figures that we have they're above our budget but here's the plan to get within that within the next you know sprint or two and get it back down there and to have that you know have those tasks in you know in your geo linear whatever to make sure those actually happen yeah yeah yeah and to you know show that there's a plan for getting it back getting it back to that baseline that you already agreed on so yeah pushback does happen sadly and yeah it does how I found is the best way to handle that and don't go along with the stress and pressure of trying to try to just you know satisfy the the business needs just for the sake of you know a few hours a couple of days yeah I'd like to flip that on a tidal a little bit like what are things that are easier about kind of building this performance first team culture like what's something that is a is a win that you can see easily yeah so I think in terms of like

1:00:46developer happiness so like I think Dora they produce these metrics every year about they do a whole bunch of surveys of developers now they're feeling about different different aspects of working and software what things are the most painful and a lot of people report you know about things like burnout and things like that because you know there's the constant stress at the end of the project to to either fix or you know get things done by a certain deadline and I think performance if it's into that in terms of the way people have always done it which is leaving everything to the end yeah and you know that to make developers happier you have to feed things in earlier on and this is no really the whole idea of like shift left and things like that that have come earlier like bringing things as early as possible so that they can be fixed before they happen later and so fast by you for as kind of extension of that idea but spread out all the way along rather than just everything we're beginning and so yeah I think that's that's really like that's really what's

1:01:48all about yeah yeah so I and I have authors on often I think about the depth they go into of writing something like this and I feel like occasionally they'll discover something new love and insight while writing the book do you have a insight that you had while writing this book yeah quite recently actually so this is more front and focus but I've been writing a section in the book about soak testing and other things are a load testing and things like that so about trying to catch memory problems by running the application over a long period of time and on the back end as you usually about firing a whole bunch of activity at your API end points and seeing what memory leaks over time and in the front end it doesn't quite work the same way because you're running in one browser some JavaScript code over long period of time and people are interacting with it and you only notice slowdowns from over a really long period of time so it could be several hours and only then

1:02:49you see the memory leaks happen okay so I've been trying to like I had a kind of epiphany that soak testing in that regard in the browser isn't about about load and isn't about like bombarding the system in that regard it's about speeding up all the interactions that could possibly happen in the front end and squeezing them down and compressing them through a short period of time so you see really quickly the way that the memory graph is going so you know instead of you know someone you know typing let's say we took her out slack and chat interfaces someone types in long message and presses send and then they click here and they click around to this different channel and they go back and they type another message and so like essentially recording that activity but playing it back really fast and just seeing the memory graph spike then you can trace it down through profile and to find out exactly what it was about that that caused the issue what's the spike you left yeah exactly where's that coming from is it I talked earlier about DOM nodes and elements on the

1:03:50page other ones that are being left behind as people click around that should have been cleaned up and is garbage collection happening fast enough and the scope of variables and things like that so that was a kind of epiphany I had I had about it and I wrote a blog post about it recently and it got some good good kind of traction in the community saying oh yeah I'm sort of about like this before and you know instead of just thinking about it like load which is how we typically think about you know measuring memory far as much traffic as we can as something and then seeing how its memory performs like firing as much traffic in the front end is really about firing as much user activity to the page as possible and seeing what happens and what comes back yeah that makes sense kind of a stress test of a sort exactly yeah it's exactly what it is yeah yeah cool yeah did you find something really difficult to put into words that you struggled with so far I know you're not completed so no there's still a few chapters to go but yeah like it's been plenty really

1:04:51like in general it's been like 10 years or more since I wrote my last book and I hadn't been blogging much until very recently so it's all kind of like just way back then my memory just like get the kind of muscle memory of like writing stuff down and a structuring sentences and things like that so there's been a lot of stuff like the architecture chapter in particular I think that's like there's probably the longest chapter of the book right now I don't know how many pages this was like 60 or something like that it's kind of kind of long yeah there was a lot to get in there and to kind of compress it down without losing any meaning and like trying to structure it in a way that you know it's interesting enough for someone who's focused on the front end to read about something that's to do with the back end and and to some people who are writing you know mobile apps to read about the front end as well because my you know my whole concept is that this is like this is a full stack problem performance it's not just yeah a front end problem or a back end problem it's everything is the way that all the software fits together the whole stack from the network up to the user so

1:05:54it's it's all about optimizing with the different parts of that and so full-statement developers will get a lot out of this but I think that people who are just back end developers just front end developers will as well and to try and make those other sections where they're not it's not there main focus be as entertains the wrong word but as engaging as possible yeah so that they don't kind of drift off during those sections that's probably been out as fun yeah I'm thinking about that with the the conversation of with you know we're having we're Python developers their stuff maybe the back end stuff it may be fast API maybe you know these different tools like this or they could be doing you know other stuff and then I have a lot of people that are you know data scientists that we'd be looking at this stuff but in a similar way you still want to look at like okay architecture what are you using are you running this thing locally are you using a web service to do all your testing you know where can you find architecture in the tools that you're using where can you find these wins and so I think that's a really kind

1:06:57of a cool part of the conversation I'm glad to talk about it yeah I have one other odd question for you but we mentioned it at the top where we talked a little bit about you know people are using L1ms to do a lot of development and the wrinkle that I'm wondering about based upon the book is well do they write performant code or is that something that you have to put into that like how do you prepare for that or is that part of the thought process at all I don't know I do actually go into this in the book okay I haven't done like the dedicated AI chapter because I think that's just that's just like AI fits into the process you know the whole process and the more that L1ms are able to do and more agents are able to go into different systems and start doing things for you I think it's that's going to grow over time so I didn't want to be like here this is what the system can do and that's it right so yeah but so by default I mean L1ms they focus more on like

1:08:03correctness and where the tests pass where the unit tests pass and so that might you know that they don't spin up an old mobile device from 10 years ago and try this try the system on that and you know see if it works you know they don't have the concept of trying things out on different hardware that might represent what your users have or what your you know your where you're deploying things so that's that's really interesting they want to answer the question and mark a check mark absolutely okay yeah that's absolutely what they want to do sometimes they'll come up with a decent performance solution sometimes they won't and so for me it's been worth doing like second passes over things when I've been coding and saying okay you know we've got this working tests passing but let's have a think about performance like what you know list me out all the areas that could potentially be a problem when it comes to performance when this is deployed and in the hands of real users and then you know there's a lot of information out there on the web and various

1:09:05different places and books and stuff about this so you know it's consumed a lot of data about this it's just because that focus initially is just about getting the code done getting it written and test passing that is not got that focus but usually a second pass or a third pass can help you get there so in terms of code review as well like this and pretty good AI code review agents out there as well that some really good tools some a bit more focused on performance than others and so those can be a good thing to have plugged into your your PRs and doing that kind of extra check at the end for you for things that you missed during development so those are really useful as well like I would say they're not a complete substitute for you know being a human in this whole yeah well the development right now but you know maybe they will be one day but I think it's that it's that feedback loop of you know the LLM not seeing how that this system application is being used in the real world or will be used in real world and being able to feed that back so if

1:10:08you have real world data that you can apply then yeah import that into your LLM. I've been seeing that in different systems like a DSPI having like these things that are if you're writing a prompt like okay we'll give it these results and I was thinking about your budget like I don't know if that's something you could inject in that and say like this is important these are the important phases of this this is what I'm allotting I don't know if that's yeah you know I guess it depends on the sophistication of at this point probably like a whole harnessed out thing that you know looks at it but yeah yeah that seems like they're all about getting code out there in some ways yeah and potentially you know helping with reviewing things and feels a little more in the prototype area so I feel like it's something that you could mistake and skip absolutely yeah absolutely so you've got to be aware of it as someone using these tools like you know the first step is correctness and the second step is performance and yeah feed in your budgets feed in and you real world data you have into the system and you know have it used that to optimize

1:11:13but just be careful not to over optimize and you know right and you know they'll premature thing yeah yeah exactly yeah yeah yeah I was actually thinking of that quote recently is that kind of like peening into a corner in a way like you just kind of like okay I'm like I'm cutting off all these different angles that I could look at performance because I've you know painted it in the way that I'm stuck you know I can't yeah I can't yeah okay yeah exactly yeah just on that premature optimization quote I read that that a bit of that paper the other day and read what came immediately afterwards which is really interesting so he was talking about micro optimization specifically they're actually like but one of the next comments that he had in the paper was really interesting and it was like I think that compilers should build in a way to present performance figures and measurements into the compiling stage so that the developer can see that and then feed that back into their development work and I was so interesting like I hadn't seen that before but I was kind of like the

1:12:15the kind of concept that I have in this book that early on thinking about yeah yeah exactly yeah so that was super interesting I thought okay this is from like 70s or something and thinking about it back then and okay we're still suffering from some of the same problems now that we were back then let's hope to you know the next 50 years that we can improve things maybe my book and I'll pre-know you suppose to yeah yeah so I like to ask people who come on the show a handful of questions here and the first one is what's something that you're excited about that's happening in the world of Python and I know it's not your main focus but yeah no it's not bad actually I read something recently I think I actually probably mentioned it before on the show but when Simon Willisson was talking about combining a micro python with wasm and runny sandboxes in the browser I had that on the show recently yeah yeah yeah yeah it's really interesting the way that like worlds combine but the worlds come in contact with each other and I've always had this idea of like sandboxing inside the browser and you know having that environment that's locked

1:13:17locked down that you don't have when you run things on your system so yeah I thought it was really interesting and yeah I'm looking forward to seeing like that extended and more ideas like that yeah coming through and wasm is really great for that for combining things written in other languages and running it within sandboxes that's super interesting and I think that's I definitely want to watch I'm going to be watching it anyway watch that space yeah yeah so what's something that you want to learn next this doesn't have to be programming related oh yeah um someone next well I have a whole bunch of like synths and keyboards and stuff locked away in a cupboard here that I haven't done all right dusted up for ages I used to be a DJ and play records and stuff many years ago and bought a whole bunch of equipment at a time and it's all just sitting in a in a suitcase in the in the closet so I just I want to take that out and get back to learning more about wave forms and things like that I've got 12 ones where you can actually actually synthesis you know really turning the dials and affecting the sound and stuff so I really love that

1:14:18idea there's a good course that I found that I might share with you oh yeah that goes through it and it actually has an on-screen synth that you then you know it says okay make a sound that does this and then you're like literally adjusting it and you're like really kind of get that feedback loop of like well let's reduce it just to like three knobs as we then expand and so forth because yeah it's in this is pretty wild and it's gotten yeah gosh way more advanced and I agree I think you know making you know just touching the knobs and playing with stuff it's a lot of fun as you can see yeah exactly I see your equipment and yeah that maybe think of it actually so yeah so that's the I want to get into and learn a bit more about yeah awesome what's the best way the people can follow your work online oh yeah so when I'm unlinked in Denodell but you can also find me on my website Denodell.com I blog about performance and some other things that I care about as well yeah yeah that's that soaked test on there recently right yeah that's right yeah exactly so that's my most recent post but yeah I write about other

1:15:23things as well like accessibility and a lot of stuff to do with how users interface with products and stuff so yeah performance is a big thing obviously I've been writing about recently and has been a kind of thread over the last kind of year that I've been blogging again so yeah find me on there and Denodell.com and yeah see if you like it well then it's been really fun talking to you thanks for coming on the show you too Chris thank you so much for having me I want to thank Den Odell for coming on the show this week and I want to thank you for listening if you like the episode a great way to help us grow our audience is to share it with other Python users but you think might enjoy it you can also leave a rating or review on your podcast platform of choice if you or your company are interested in sponsoring the podcast you can find all the information at realpithon.com slash advertise you can find show notes with links to the topics we spoke about inside your podcast player

1:16:27or at realpithon.com slash podcast and while you're there you can leave us a question or a topic idea I've been your host Christopher Bailey and I look forward to talking to you soon