live. Thank you for joining us again in this new year. Hope everyone's doing well. Without further ado, I'm going to jump right in here. Holly Cummins has agreed to join us today to talk about polar bears and something about Java, and she's going to tell us all about it. How you doing Holly? Yeah, very well. A little bit about Java, a little bit about performance, but you know mostly about polar bears, right? Mostly about polar bears. Polar bears are a good topic. Especially when it's cold. It's cold and gray in Atlanta right there. If you can't see up my back window here, it's all snow. Would you like us to interrupt you with questions and chat or do you want to hold them till the end? How do you feel? Yeah, let's interrupt with chat.  I'm happy either way. Okay, yeah, we'll probably have a bunch at the end, but if somebody puts something in the chat, we're happy to interrupt your train of thought.  So, I don't know if we've had you on before. Maybe a little bit about yourself and then before you get going. Sure. So, I'm Holly Cummins. I've been with Red Hat for about two years now. I work in the Quarkus team and so I do all sorts in the Quarkus team. I work a lot on ecosystem and I work a little bit as well on performance and looking at the various aspects of Quarkus performance. But I've had sort of quite a mixed career. I've been a consultant. I worked on application servers, but one of the things that I did when I was first starting my career was I worked as a performance engineer on the JVM.  So, I sort of stuck with that performance theme through the rest of my career. Oh, that's a good background. How does the Quarkus thing work with performance? Is that something on top of what you're doing? I mean, on top of the JVM when you're thinking about that or is that like just the compiled stuff? I'm sorry, Jeremy, I cut right over you. I do it all the time.  So, how does that relate to Quarkus? I guess is where I'm gone. So, with Quarkus, I mean, we do a lot of work on performance with Quarkus because going fast is one of the things that we really want Quarkus to do. Quite, and I'm not the one who's doing, I should say, I'm not the one who's doing the main Quarkus performance work. There's some really clever people, like Francesca Negro, who are just making improvements all across the board. But a lot of what we end up doing when we look at Quarkus performance is actually looking at all of the libraries that we're built on and how they interact, but then also just what's going on in the library. So, we end up doing a lot of performance-related pull requests to places like Netty because Netty is somewhere in the Quarkus stack. And so, if Netty goes faster, we go faster. But then, of course, if Netty goes faster, then quite a lot of the world goes faster as well. So, it's sort of, I think it's a really nice example of the power of open source that because we're built on these open source frameworks, we have the ability to make them go faster and then we benefit and everybody else benefits as well. That's a very cool point. Yeah, because Netty is pretty ubiquitous, right? Yeah, yeah, completely. Yeah, what I was going to say earlier, I had a, so I was at Boy Scouts, right? I had a conversation with one of the other dads waiting there outside of Boy Scouts. And he brought up this thing that a long time ago, like performance really, really mattered because on the mainframe, if things chewed up, you know, resources, you paid more money for that. And we, you know, in the Java world, you know, in most of my career, we never had to worry about that, right? Because memory was cheap. Yeah. And like, you just use all these servers with a lot of memory. And now that people are moving back into the cloud, memory is a thing again, right? And you're looking at your resources. Yeah, completely. You've just like anticipated my first eight slides or so. But it's exactly there you go. But you're right that there is always, there is always a trade off, because it used to be that hardware was incredibly expensive, and developers were relatively cheap. So you wanted to get the most out of your hardware you could. And you're willing to spend a lot of development time to do that. Now, hardware is pretty commoditized, pretty cheap. And developers are pretty expensive. So the balance has shifted that because, because writing performance code takes that optimization effort. And then it's also maybe not as readable, maybe, well, in some cases, you know, when you go for those really hardcore performance optimizations, it's maybe not as readable. And so then you do kind of say, well, I need to be pretty strategic in where I optimize. And where I don't optimize because I don't want to have this hyper optimized mess of a code base that nobody can maintain because developers are expensive. But I'll just I'll, I'll, I'll scooch in actually, because I have, I have a slide that sort of, you know, on this exact thing, because although, although as you say, I think the balance has shifted now. And we, we maybe think of optimization as something that we do a little bit less, because our frameworks take care of it for us, our platforms take care of us for it. It still is really important as, as people making things, we, we still do have to be making sure that by whatever technique we do it, that thing performs in a reasonably good way. And the reason is because as developers, we, we build things to be used by people. And people get cross if stuff is slow. And, and we can really sort of quantify even small performance impacts can have quite a a big sort of knock on effect on the experience of users. So like many years ago, Google found that if they had half a second extra on the time it took them to return search pages, the traffic dropped by 20%.  And Akamai did some research, and they found that if they had an extra 100 millisecond latency on their page loads, then the conversion rate was 7% lower. So again, you know, we're seeing this sort of direct commercial impact, this direct direct money impact from performance. And both of those studies were like five or 10 years old now. So I think now user expectations are so much higher. And you would never tolerate half a second or extra on your search page. You'd just be like, I have other search engines I'm going to buy. So the impact would be a lot more than 20%. And then of course, you know, there's sort of, so those are kind of indirect commercial things where we make users annoyed and then they, they take their business elsewhere. But of course, for some industries, there's like a really direct correlation between the performance and the money. So if for example, you're working in high frequency trading. And of course, if you're working in high frequency trading, hopefully this isn't your introduction to performance optimization, hopefully you've already got it sorted out. But those high frequency trading platforms, they are so sensitive that just, you know, like a 10 millisecond delay in the trading platform will give you a 10% drop in revenue. So it's super strongly correlated.  But what, what exactly is it? Fundamentally, optimization is making it go faster. But, you know, that's just like four words and it sounds really easy. But it's not actually that easy, because then you have to sort of ask, follow on questions, like, for, for who is it going faster? And when is it going faster? You know, what time of day is it going faster? And what are they doing? Because although performance and optimization, it sounds like just one thing, there's actually a whole bunch of different things that we could be trying to optimize. And of course, if we optimize the wrong one, then we just wasted a ton of time. So performance can be throughput. And I think that's probably what most of us in maybe initially think of when we think of performance. So that's like your transactions per second. It can also be latency. And so that's things like for an application, maybe it's the startup time, or definitely we think of latency in terms of the response time. And then also for something like Java, when it first starts up, the jit hasn't really done its thing, and it can be a bit sluggish. And that's true for actually all applications, but it's just more noticeable for Java. So we also need to think about things like ramp up time. So if you get up to full speed faster, that can improve your throughput, it can improve your latency. So it's sort of between the two. And another aspect of performance that matters a lot is capacity. So that's how much of the thing can I do. So that's, for example, something like bandwidth. So and I, of course, when I do this talk online, I always think a lot about bandwidth and I care a lot about bandwidth because, you know, sometimes my bandwidth isn't high enough. And then the whole talk is a bit of a disaster because there's no bandwidth. But in a cloud context, another aspect of capacity that we care about a lot is footprint. So if I'm paying for one virtual machine, how many of my applications can I host on that virtual machine? Because that's going to affect my costs, like you said, Jeremy. And another sort of related thing that you might not think of as a capacity thing is CPU usage. So if my application takes 100% CPU, I can only run one of it on a machine. If it takes less CPU, I can run more of it. But I mentioned it gets complicated and it gets really complicated. So when we think about capacity, we want to lower our CPU usage because we want to make sure that we could fit as many things potentially fit as many instances of the application on a box as possible. But the other thing that we probably want to optimize is our utilization. And so to optimize our utilization, we want to increase our CPU usage. And so sometimes what what performance engineers will be doing is trying to drive the CPU usage of an application up because that means that they're using the system more efficiently. So it gets complicated. And you know, the other thing about these things is, you know, just like capacity and utilization where you seem to have these contradictory goals. For a lot of the others, there's a tradeoff. So we kind of like a lot of us will sort of instinctively expect that, you know, maybe if you increase your or improve your latency, then your throughput might go down. So if you have something like natively compiled Java, that's often the tradeoff that you're getting is that super rapid ramp up time. But at the expense of maybe lower throughput. And these tradeoffs are, you know, something that we've been dealing with as an industry for a really long time. So I don't know if you've heard the quote, never underestimate the bandwidth, but which they mean throughput in this case because it's so confusing. So never underestimate the bandwidth of a station wagon full of tapes hurling down the highway. And that, you know, was back from 1981. And I always thought this was like, you know, just 1981. So that could be VHS or a tracks. So yeah, that's a pretty funny saying. I never saw that before. How did you never because I'd seen it before. But I always thought it was one of those things that, you know, people just make up. But it's actually based on a true story. Because there was two NASA sites in Texas. And they had a data pipe between them. But that data pipe got broken. And so they switched to to communicate between the two sites. They had this like NASA station wagon. And they put all of tapes. And they're like physically driving them down the highway.  But the thing is, this is actually still how a lot of data is transferred in 2024. So when Google transferred data internally, and when it's, you know, these huge volumes of data, they don't send it on a wire. They physically put it to a physical medium and they, you know, carry it to the other place. And yeah, and same for Netflix, because again, you know, Netflix, they're they're a data volume business.  But internally, they are still transferring the media on physical media. Because, you know, like the thing with sneaker net is great throughput, terrible latency. And now I can't help myself but interject a dumb story. So in 1992, we used to stand in the data center and there was the spindle on the, you know, the mainframe. Think of it that way, not not just tape cassettes. And we take the tape reel and see how far we could stand back and throw it and see if it would land on the spindle. So you accepted the mainframe never goes down as a challenge. Oh, yeah. I've got a mainframe going down story next, actually.  And then like requirements change, because the world changes. And, you know, this is exactly what you were talking about at the beginning, Jeremy, that things change. And so we, some colleagues of mine helped a client a while ago, it was a South African bank, and they had this mainframe system and it was designed for the tellers to use it at the end of the shift. And it worked great for that. So the idea was that, you know, they had a small number of tellers and at the end of the shift, they push a button and then it would fire off the request. But then there was this handy API. And some other people in the bank had a mobile API. And they thought, hey, we could connect our mobile system to this handy API on the mainframe. But of course, the number of mobile users was hugely more than the number of bank tellers. And the frequency of transactions was way, way more. Because instead of being once at the end of a shift, I mean, you know how we use our phones, right? It's just scroll, scroll, scroll, refresh, refresh, refresh. And so this app was just sending requests back and forth and back and forth. And so it was just this sort of, you know, bombard. And when we talk about performance and SRE and that kind of thing, we sometimes say slow is the new down. But of course, down is the old down and it's the worst down. So this mainframe, it just completely collapsed. Because the, you know, the original system design, it was totally good for the context in which it was designed. But then the world changed and it hadn't caught up. And, you know, now we're seeing this really big change because you may have heard of the cloud. And in the cloud, you know, as Jeremy said, there's this really strong correlation between how much memory you use and your cost. So all of a sudden footprint is something that we need to care about a lot.  And so I used to, when I was a performance engineer, I worked on the J9 VM. And many years after I left that team, it was open sourced, which was really cool to see. And then shortly after it was open sourced, I started to see all of this stuff on Twitter where people were saying that they had switched to J9 and their performance was way better, which, you know, I was pleased by because I used to work on J9 performance. And we always knew it was a really performant runtime. But if you dig into it a little bit more, what it actually, what had changed was that cloud footprint thing, which is the characteristics that J9 had were, you know, so it had, I think, I think it had a lower footprint. But as well, what it had was it had this faster startup time. And so in the cloud, you care about footprint. And you also really care about startup time. And so J9 started faster than hotspot. And it had, yeah, it had that middle chart, it had that much smaller footprint after startup. But there's always the tradeoff, right? So if you look at the right hand chart, what you can see is it got to peak performance faster, but peak performance was lower. And we see a kind of a similar tradeoff, but like turned up to 11 with GraalVM. So with GraalVM, you can have this astonishingly tiny footprint. And you can have this astonishingly fast startup time. But the tradeoff is that you will probably have slightly lower throughput. And so Quarkus has done a lot of work to integrate library so that they're easy to use with GraalVM. And so I heard a story, this was before I joined the Quarkus team, that we were at a conference and we were at a booth. And one of the booth staff was I think maybe a project manager or a product manager or not super, super technical. And so every time someone would come to the booth, they'd say, hey, do you want to see Quarkus? Do you want to show you how fast Quarkus and GraalVM starts up? And the person would be like, yeah, cool. And it was only at the end of the day that they realized that they had never actually thought to shut down any of these applications. And they had 120 instances of this application running on their machine. But the cool thing was it didn't actually matter, because the footprint was so tiny, their machine just carried on. I'm thinking how this is relevant to a problem that I faced last year where a bank, to use your example, needed to start things up. Certain use cases were first in the morning. Most people check their balances around lunchtime, but aren't actually doing any banking. They're just checking their balances so they can go to lunch. They might make it go to an ATM, do a withdrawal, and then do their online banking later in the day. But that shifts based on what time zone you're in.  And do it based on time zones, based on use cases across time zones. So that saves a lot of money. Yeah, completely. I think it's something that as an industry, again, we need to be going towards is just supporting much greater elasticity. And there's a few ways you can do it. So like, if you have something serverless, then that's ultimately elastic, but then there's some trade offs with serverless. And a pattern that, so the other thing that you could do is you can have like an auto scaling algorithm, but it may not respond fast enough. You can use, like you're saying, Rob, when you know the pattern, and you know it's at lunchtime, you don't know what time zone lunchtime is, but you know you are going to see these peaks and troughs, then you can have something that's a bit more predictive either through machine learning or through manual training. But another pattern that I really, really like is kind of like the equivalent of cloud bursting, except for for sort of workload run times instead of hosting region. So the idea is that you think you're going to run most of your workloads on Quarkus on JVM, because Quarkus on JVM is going to have, actually, yeah, so we've got, with Quarkus on JVM, you still have a better startup time than you would if you weren't using Quarkus, and you still have a better throughput than you would if you weren't using Quarkus, but then you also have this better throughput, and then the developer experience is better as well. So it's sort of this really nice all-rounder, but it's not going to be the same as GraphVM in terms of its, you know, how tiny the footprint is and how fast it starts up. But you have the bulk of your sort of, you know, your day to day on that. And then you have a sort of a scale up and scale down with Quarkus on JVM. So the idea is when you get a spike in workload, you can respond to that spike so fast, because GraphVM starts so fast that you don't need to keep that capacity always up. The sort of the one caution with that, which is kind of interesting, is that like what we find is GraphVM will start in like 15 milliseconds.  But then sometimes the sort of the surrounding framework, like your serverless framework, or you know, your whatever, is actually going to have a much slower startup time. And so even the Quarkus sort of then isn't the bottleneck, but you still do need to to deal with the bottleneck in terms of your elasticity. But often even like, even if it's a second, you know, that's enough to allow you to have a good enough elasticity. Well, so and so a lot of one thing we often talk about with GraphVM is the ability to compile down to native code, right? But does this, I mean, is it fast enough so we don't really have to worry about that? Or does native give us much more of an advantage? Um, I'm not, I'm not sure really. Okay. Yeah, it's a good question. Let's come back to that one. I'm going to interject there just from an edge perspective, because I do a lot with edge customers. You know, usually they're not on Java, but from an edge perspective, if I can compile things and have a smaller size and a faster startup, I get two things. One is when I when I want to do an update or push something down to the device, I'm not using bandwidth, right? And I've had customers where it takes an hour to get something updated because they're pushing something from the US to Singapore or whatever, right? Yeah. Then the startup time is important because normally on an edge device, you think of it as I have software that needs to be up and running all the time. Well, that is true for the main thing. But if I want to say filter data, upload data, check for updates and do some other things, I might want to do that when my main event isn't happening, right? So I might have 20 minutes window to do something to upload data or whatever, and I want to leverage the resources I have available at that time.  Yeah. So and size matters there and startup time matters. And I know I'm going to shut it down when I'm done because I'm going to reclaim those resources for the primary software that's doing its job. Yeah. So edge, that would be a big important thing when we talk to people doing stuff there. Yeah, definitely. I always get really excited by Quarkus on edge because they just seem like such a natural fit. It does seem. Yeah. Yeah. And there's sort of like, I think for some scenarios, you definitely do want to be going to that girl VM. But what we see a lot of times is people get really excited by the girl VM because it seems so miraculous. But then they look at the trade-offs and they're like, oh, well, actually, this isn't really the trade-off I should be making. And with Quarkus on JVM was kind of amazing. And what's completely counterintuitive is that there is no trade-off because you kind of like wait for the, you know, okay, well, which am I trading off? And it's like, well, it goes faster and it's smaller. So like, why wouldn't you? And I think normally when you know, when you're doing performance tuning, it is always about the trade-offs. But I think there is occasionally this magic scenario where actually there is no trade-off and what you've found is you found waste. And so you're able to eliminate the waste. And so that's what a lot of Quarkus is doing. And of course, then, you know, well, what is waste? Why is this waste here? And the waste that Quarkus is getting rid of is that Java historically has been super optimized to be really dynamic. And in the cloud, like you're not patching your server live in the cloud, you're just pushing up a new image. So you don't need that kind of dynamism anymore because we make more decisions at build time. And so, you know, then that really is waste because there was this trade-off of dynamism versus performance. And it's like, well, we don't, we don't need the dynamism. So we have, we have somebody from chat who's kicking who suggested that we, if it's a longer running process, you also get better throughput on the JVM. Yeah, for sure. Yeah, for sure. So your ramp-up is probably going to be faster with, with native, but then, you know, the longer it stays up, the more... Did you see who that was from, Holly? I didn't know... It's from Eric DeAndrea. Yes, nothing but a troublemaker, right? Hey, Eric. So just to sort of, you know, summarize, because this is a question we get a lot in terms of, you know, choosing which Quarkus you should use and which is faster.  If you're running your application for a long time, exactly as Eric says, maybe go for, for OpenJDK. But the other problem with requirements is that, like, often, you know, we think we know what the requirements are, and we actually don't, so then we optimize for the wrong thing. So for example, how often do we optimize for the behavior at idle? And when you optimize for the behavior at idle, what you're really optimizing for is the application that you worked so hard on not being used. And that's depressing. So, of course, nobody wants to imagine that they're writing a thing that doesn't get used. So we don't optimize for that. But realistically, like, we probably should, because about 30% of virtual machines out there in the world are what's known as zombies. So these are just machines that are being used, and they haven't done anything useful in the past six months. So really, you know, when you think about that kind of scenario, I mean, it's a depressing scenario, but the lighter you can make your application, the better it is if it's depressingly not used. So how do you, assuming you want to optimize, what do you do? So again, you know, a bit like making it go faster, this seems really easy. The thing to do is to find the bottleneck, and then you fix it. And, you know, what could possibly go wrong. There's a whole bunch of pitfalls here. The first pitfall, interestingly, is intuition. I love intuition, but performance optimization is not the place for ideas. You've really got to be guided by measurements. And it's more than that as well. You've got to, you know, you can't just measure things. You've got to measure the right thing. And what that is, is what your users care about. But it's really easy to just measure things and then assume that we're data driven. And this is called the Mykonomara fallacy. I was super interested when I learned about it, which is basically like if you, it's a good trick to use actually, you know, and meeting to that kind of thing, if you can show numbers, even if the numbers don't really make a whole bunch of sense and you measure the wrong thing, people will assume you know what you're talking about because you have numbers. We all have this kind of, you know, we love numbers. But measurement theory is really interesting. And, and there's this whole idea of leading indicators and lagging indicators. And this is actually something, this is like a business thing, a management thing, but it's super useful for us as techies. So the idea is that the lagging indicators, these are the things we care about, like how much money is my business making? They're super easy to measure. How much money is my business making? I just look at what revenue is coming in. But the only problem is they're hard to change. How do I make more money? And then we have leading indicators. These are really easy to change. I should, you know, buy everybody MacBooks. I should, you know, whatever. They're, they're predictive of a thing we care about. If I buy everybody MacBooks, then we'll make more money. But the problem is that they're really hard to identify. You can't figure out what is the thing that you should be changing to change the thing that you care about. So it's tricky. And I wanted to to show some examples of like how these work. And I should say like with performance, you know, we all want to be guided by other people because we, none of us have enough time. These performance experiments are for entertainment purposes only. You could try these at home, but please do not use these to tune your production system because your context will vary. Your answers will be different. So way back 15 years ago, I did an MSC and my MSC thesis was about garbage collection. And one of the things that drove me crazy was that there was, you keep seeing this bad advice. And you see it in like books and everywhere that says, ah, to optimize your application, what you want to do is you want to reduce the amount of time spent in garbage collection. And this is just such bad advice because garbage collection, it's an investment.  And you can see this, like just by, you know, trying things out. And so back in 2007, I did this performance experiment. And the two lines here are how much time you're spending in GC. So with the blue line, every single time it did a garbage collection, it compacted. That is a ridiculous thing to do. The over the GC overhead in that scenario was huge. But you can see when you look at the throughput, the blue line has a slightly higher throughput. So even though we're spending like twice as much time in GC, we actually made the throughput better. Because compacting rearranges the heap and it makes object access faster. So I thought I will recreate this experiment for this talk. So I went and I found the day trader benchmark. And then I've wired it up with Jmeter. And I started doing my experiments. So the first thing I did was I set it up like I had done back in 2007. That didn't work. So then I made a few changes that didn't that didn't show me what I wanted. So I tried setting the heap. That didn't work. So then I tried changing, you know, I tried setting the heat to a different thing. And no matter what I tried, the performance stayed exactly the same. And of course, this is totally cheating. This this is exactly bad science. When you do an experiment, you should not be trying to adjust the experiment until it shows what you want to show. That's not science. That's yeah, that's cheating with numbers. So eventually I kept, but I didn't care. I just wanted to write my talk. So I kept changing things around. And eventually I got a setup that showed the effect that I wanted to show.  And what I could see is in the first scenario, I spent 21 seconds in garbage collection. So it was about 4% of my time was in GC pauses. In the other case, I spent 12 seconds in GC. So it was about 3.6% of my time in GC pauses. So I'd lowered the GC overhead.  It was because in the bad case, I collected 24 gig of garbage. And in the good case, I collected 13 gig of garbage. So I spent twice as much time in GC because I did twice as much work. And at this point, you should be starting to think, Okay, actually, I'm not sure lowering the GC was such a good idea. And if you look at the transactions per second, you can see exactly that I have my throughput. And I have my garbage collection. So and again, you don't know which way around the correlation is here. But, you know, definitely it's not it's not what you expected. And this is a super good example of lagging and leading indicators.  But if you try and improve your throughput by lowering your GC time, you're going to be going in the wrong direction. It's not it's not the right leading indicator. But then as well, you probably have to think a bit more deeply about it to and say, Well, wait a minute. Is that even the right lagging indicator? Like here I've optimized transactions per second, because it's what I care about. Well, it's what I think I care about. But maybe I should be optimizing latency. Maybe I should be optimizing something else. So you know, you do these experiments and you have these numbers. But you know, you're not necessarily optimizing the right thing. And I, I haven't as well said what I changed in order to make that really big behavior difference. When you're doing performance testing, everything always says you cannot run your, well, you must not run your load on the same thing, on the same system as the application that you're testing, because otherwise, the load generation consumes resources. It turns out, in 2024, laptops are, this was just my laptop, which is again a terrible place to do performance experiments. My laptop was so fast that the bottleneck was the network. So the bottleneck was the network off to jmeter on a different machine. As soon as I put jmeter on the same machine, my throughput doubled. So again, I wasn't really measuring what I thought I was measuring at all. I was measuring the impact of the network, not anything to do with, with GC. And again, this comes back to this idea that you've, you've got to find the bottleneck as your first thing. Because if you're making improvements somewhere that isn't the bottleneck, in this case, the bottleneck was the network. It didn't matter how I tuned my GC. It's just an illusion. The other thing to really bear in mind is that like time kills all performance advice. Even my performance advice, you know, it's not going to be the same now as it, as it was then. So for something like ZGC, you know, that's, that's new. And it has these pretty amazing pause times and a pretty small trade off. So we always used to say, don't do concurrent GC, because your performance trade off just isn't going to be okay. With ZGC, it is a pretty okay trade off. But there still is a trade off because your memory consumption is a lot higher. And I don't have good numbers for how much higher the memory footprint is with ZGC. But I know with Java 21, they added generational ZGC. And that reduced the footprint by 75%, which tells me that if you can reduce the footprint of something by 75%, you weren't going to like what it was before. It must have been pretty big, but I don't know.  It rearranges the heap that can make your application go faster. You need to find the bottleneck. Don't trust performance advice, validate it independently, and make sure you're measuring the right thing for you. And that brings us on to the next bottleneck, which is advice. All of us want to learn from experts. And unfortunately, that means that we read the internet, which is not necessarily the place to find experts, particularly with time. So the internet is just filled with bad advice. So like people, you can still find things that say, you know, in Java will make one big method because method dispatching is slow. That hasn't been true for like 15 years.  Almost always, this is a terrible idea because it really, really hurts generational garbage collectors, which is what you should be using. And then you find things like, if you want to tune your JVM, use this command line, and they just get cut and pasted. And Ben Evans has this lovely story from when he used to work at New Relic, because they could see all the command lines that were run. And for one of the parameters, you know, we always tend to do it like a power of two, 256 or something. And for one of the numbers, it wasn't a power of two. And they worked out that what had happened was one person somewhere on the internet had made a typo. And that had propagated to something like 17% of the JVMs that they had in production, this wrong number. But, you know, we all want to do it. And then you get advice as well, like, you know, you should never concatenate your strings with plus equals. You have to use a string builder. And then this is where it gets really complicated, right? Because that is actually sort of correct. But it's sort of not correct because now the JVM will optimize it. And the optimizations are getting more and more clever. So again, you know, you have to, you can't just trust these things that you read on the internet. You have to try it out. Because time ruins all advice. And this plus equals is the sort of optimization that a lot of us really like doing. So like if we get a code review or something like that, and we see our buddy has done plus equals, we'll be like, oh, yeah, you should use a string builder. But we don't necessarily know if it's actually just going to make it faster. We just think it will. So I decided to try it out again. I did another slightly dubious experiment. So everybody knows that string concatenation is slow if you do it in a loop. So I made a huge loop, and I did loads and loads of string concatenation. And I went through the my my benchmark, and I found a place where it was doing string manipulation.  And I tried out my benchmark expecting to see the performance fall. And there was no difference at all. None. So I was really depressed. And I tried to figure out what had gone wrong. It turns out the method that I was worsening, deoptimizing was a two string method. It never got called. So it didn't matter how crappy or how amazing the code in there was, it never got called. And like we do this, we do this everywhere. It's just such a natural thing that we want to optimize. And we tend to optimize the things that are easy to optimize, even if they don't necessarily have very much impact. So, so like I think a lot about carbon. And when I when I travel places, I will always try and take public transport to and from the airport. And sometimes it's a lot more expensive. Sometimes it's a little bit scary. But you know, I kind of think, well, every little helps. But actually, like the carbon footprint of the plane compared to the carbon footprint of me taking a taxi to the airport, it's so small that even though there is still a tiny benefit to me taking the bus, every optimization that you do is taking your time from another optimization that might have more impact. So there's probably things I could do with that time that would have more impact. And it also psychologically, you know, it makes you feel like I have optimized, but you didn't actually measure to see whether your optimization was having an impact. And often, you know, going back to the conversation that we were having at the beginning about whether since developers are expensive, we should be spending time in optimization. The answer is often we shouldn't. Because if you have code like this, the JVM probably, oops, sorry, if you have code like this, the JVM historically hasn't been able to optimize it. But I think now it maybe can code like this, where it's not in a loop. The JVM will optimize it for you. The JVM will turn it into string builders under the covers. And so the like the people who write the JVM, they have so much more time for optimizing than any of the rest of us do. And so you want to take advantage of the optimizations that they're making. And the best way to take advantage of that is to write really average normal code. Occasionally, you will have to write code that's icky. So like with Quarkus, we found a really interesting bug with instance of checks. And we had to get rid of a whole bunch of instance of checks and replace them with much icky or code, because we'd identified a JVM bug. But like that was because we were working at a really low level. And because we had the data to tell us that this was something we had to do. Otherwise, normally you shouldn't. And again, you have to be guided by the data. So in Quarkus 2.0, we actually went through a similar sort of thing. We took out a whole bunch of plus equals and we replaced them with string builders. And it was because with a fairly an older version of Graal VM, there was a performance bug that we found, which meant that all of a sudden all of those plus equals were a performance disaster. So we had to go through and take them out. But again, that was a very specific scenario where we had an outside change that meant that we saw performance regression. And so we fixed it. So you've got to be guided by the data. Another trap that I think a lot of us fall into is this love of the shiny. And so for example, for us in the Java world now, the shiny is Lume. And we all want to go to Lume because we imagine it's going to fix all of our performance problems. Lume is really good at waiting. So switching an application to use Lume if the application does a lot of waiting is a great move. Lume tends to not be so good at CPU bound tasks. So if your application is CPU bound, Lume is not going to give you anything. And the other thing is that Lume can interact really badly with libraries. So one of the sort of the gotchas with Lume is that if a virtual thread, which is what Lume gives you is these virtual threads, if it gets pinned or if it does a long CPU process, everything on that virtual, everything sort of on its carrier thread will grind to a halt. And what we're seeing is that some libraries will end up pinning threads because they weren't designed for Lume. So for example, our colleague Mario Fusco recently put in a performance fix to Jackson going back to what we were talking about at the beginning about you know, sort of interacting with the ecosystem, because they pinned the thread and then that interacted really badly with Lume. So do try Lume, but just be aware Lume is not a magic faster thread. Lume will only help you out if thread management is your bottleneck or if you need some sort of better programming model for thread management. And again, you know, at the risk of repeating myself, you have to measure, don't guess. For Lume in particular, a useful measurement tool is that there is a JDK option to trace the pinned thread.  So you want to turn that on at some point in your testing. If you're using Quarkus, you have an option so you can have an at should not pin annotation on your tests. And that will give you that nice fast feedback cycle that you get the failure at the unit test stage without having to read all of the traces to say this has to not pin because otherwise it's a performance disaster. If you did want to know more about Lume, my colleague has written a whole bunch of really good articles about it. That's worth looking at. But we still haven't really talked, we've talked about all of what not to do. We haven't talked about the what to do. So when you're doing any kind of performance optimization, you're going to need tools. Historically, we've talked about performance tuning tools. Now I think there's a really nice intersection with observability tools because you cannot demise it unless you can observe it. So observability helps a lot. Performance tools, they fall into a few categories. So you can have things like your method profiler. So things like visual VM or mission control or IntelliJ has a nice profiler built in. If you're using OpenJ at day nine, there is a nice profiler called health center, which I mentioned because I wrote it and I'm proud of it. More generally as well, flame graphs are super useful for optimizing. You're also going to want to look at your GC gain a tool that a lot of people still use is GCMV, which makes me happy because I wrote that one too. You're going to want to do some heap analysis probably. The de facto tool for that is Eclipse MAT. If you want sort of a more of a one-stop shop for all of this, then you can go and you can look at a category of tools called APM. So that's application performance management, I think. Most of these, unfortunately, are not open source, unlike a lot of the others that I just mentioned, but there is one called GlowRoot that is open source. I haven't used it personally or you can go to something like your new relic or your app dynamics or your Dynatrace. Another cool trick that I mentioned just because I read it yesterday and I thought it was cool is that there's an easy way to generate flame graphs, which is using the async profiler and the AP loader and JBang. So if you can start your class with JBang and then you can just point the Java agent at it and then you'll get your flame graph. So that's nice. And this was, if anybody's doing the billion row challenge, this was the method that Gunnar recommended for doing that kind of micro-optimizing of those small applications. Of course, we all know that micro-optimizing is something that we shouldn't do. And in a microservices world, if you optimize just one application, I think that probably counts as micro-optimizing. So we do kind of need to look at distributed tracing as well so we can get the big picture. So there you're going to want things like Zipkin or Yeager or now all of those have really been subsumed into open telemetry because you do need to have that whole system context to know what to optimize. And you also really need to think about the outliers. So there's a thing that performance experts don't tend to look at the averages. They tend to look at the distribution and how bad the distribution is because that's where people get really angry. It is when they have a really long wait. And of course, the other thing is that when we're in the cloud, if we have something that's just a little bit wrong in terms of its performance, that can be a really big cloud bill. So I can breathe. So while you're taking a breath there, yeah, tools like Sysdig and Data. They use something called EBPF. And EBPF, you know, extended Berkeley packet filters, people think of it as networking, but I can use those, those tools use something called the user level statically defined tracing so that I can catch all the GC events in your JVM and user space basically in Linux anyway. The point is, maybe you can answer this now or at the end, what are your thoughts on those kinds of tools? Because even though the tool itself runs blazingly fast because they're really designed, EBPF is designed to catch kernel events. What you're really doing is, you know, you're hooking into and seeing every little event that's going on inside the JVM. And if you're running something like on a Kubernetes cluster, you think of each host node now running many JVMs in those containers and think of all the things that you're hooking in order to do that. And is there a penalty for that? Is there, you know, you know, what is the price for observing something?  The physicist, most of Jeremy's bugs are boar bugs. You know, they're easily repeatable. All mine are hyzen bugs. I can't repeat anything because I'm observing it. So, but when I'm doing performance analysis and I hook something in, invariably observing the performance of it impacts the performance of it. So what are your, you know, what are your thoughts on that? Yeah, I mean, it's a really tough thing. And I think there's sort of the answer falls into two categories, you know, same as everything. One is that there are tradeoffs. So at some point, you're going to have to decide how much do you want to have that observability, how much do you want to have that really low friction access to performance information, because that's going to have a big technical benefit against how much you want to go fast, because that has a technical benefit. And then the other side is look for the low-hanging fruit. When you can get something for free or almost free, take it. And so, going back, I showed Health Center really briefly on one of the slides. And one of the things that it did was, I thought was so cool. It wasn't my idea. But the JVM is already profiling your application in order to know what to optimize with the JIT. And what a lot of profiling tools will then do is come on and add an extra hook to recollect that information. And usually, they will have to, because that is so expensive, you have to narrow down where you're going to look. We can't collect across the whole application. So let's just look in this package. But that's going back to that first pitfall of intuition of, I don't trust the developer who wrote that package. So I think that package is where the performance problem is. So I'm going to only profile in that package. So then you don't know all of the other things that might be the bottleneck that you're missing. So the broader the net that you can cast, at least at first, the better. And so with Health Center, because it was reusing information that was already being collected and just exporting it out of the JVM. And that did have a cost, but it was only a really small cost. It meant that you got your performance information for free. So where you can do that, you want to do that. But sometimes you can't. And then you're stuck back to trying to do those trade-offs, also to try and get your feedback loops as small as possible, which is a slightly different thing. But I was just looking at a talk recently, and I haven't watched it yet, but it was talking about getting incremental functional regression testing just into your daily workflow. So that if you are catching these problems really early because performance testing is so quick, then that means that you can maybe afford to have a bit less observability in production because you have fewer things that escape to production. Whereas if you're only discovering your performance problems in production, you're going to have to invest a lot in terms of overhead in having that full observability rig in production. So Eric, I'm going to change subject here for a second, but Eric was answering some questions about some perceived optimization. And earlier, you spoke about old wives tales about things that used to happen in the past. And I've seen people tell me, don't put curly braces. If you only have one line of code in your loop, don't put curly braces because it's faster. Or in order to optimize a switch statement, put the things that are probably going to get called first at the top. That's kind of like nonsense optimizations at this point, but from my perspective, but are those the things you're referring to when you were talking about stories that don't hold water over time? Yeah. I think a lot of these things, they're either appropriate for one context, but not for others. So I saw it talk once and I can't remember it was either like it was Martin Fowler or Grady Butch or someone like that. And they were talking about how they were optimizing their code to be lightweight. And by lightweight, they actually meant physically light. They needed to minimize the number of bits because each bit had a weight and this code was getting shipped to the moon. So for that context, they really had to do things like making the variable names short and all of those things. And actually for JavaScript, then you still have that same sort of thing. But for this really specific scenario, there was optimizations that they wanted to make that for the rest of us we shouldn't worry about. So that sort of one category is that we sort of look at what people are doing in a really performance sensitive context and we apply it to us who are not in that context. And then the other thing, as you say, is that stuff changes. So probably once upon a time there was a compiler where braces would cost you cycles in terms of your execution time. But that was a long time ago, but we still kind of have that tribal memory of that. And then we pass it on even though it's wrong. And then things change fast as well. Like the JVM, every version, the performance characteristics are different. So things that optimizations that the JVM didn't use to make five years ago, it does make now. So you just have to always be guided by measurements and really invest in having that performance testing set up that is really idiot-proof and easy to use so that you can validate these things instead of having to kind of go off the, oh, well, it's too hard to test performance. Or I can only test it in a microbenchmark because microbenchmarks usually give you the wrong answer. So I'm just going to go off what I read on the internet. And one other thing before we jump back to the bears. So what about Lambda? Somebody in chat asked about Lambdas. Are Lambdas less performant than writing old-fashioned, fully full classes or putting that in other methods or classes? Oh, that's a good question. I think that's probably another one where things change. So I remember when Lambda's first came out, some performance experts were looking at the performance of them and they found that they were pretty, or certainly you could use them in a way that was pretty catastrophic for performance. And there were some fun talks that went round of like, look at this disaster that happened when I switched to Lambdas. I think probably a lot of that has gone away now and there's a lot more optimizations. But yeah, I do sometimes wonder that as well. Like when, you know, it's sort of inflating a stream and then deflating it. And, you know, is that, and it's going to depend on context a little bit. So for some things, when you can deal with a stream, you're actually going to be better off because you were never getting to the end of the stream. And so if you, if you deal with it as an object, that whole object has to be sort of constructed, whereas if you deal with it as a stream, then you save a bit of pressure on the garbage collector. So for some cases, you're definitely going to be better off with a Lambda and a stream.  But it's probably going to be quite hard to find a good answer. Because when you look for it, you will find answers from 10 years ago when there was all these performance disasters for Lambdas. But yeah, super good question. I haven't thought about the performance of them for ages. So I don't know. I try, I will not keep this from bears any longer. I know, I know. Yeah, because we talked about bears at the beginning, and then I talked and talked and talked, and we didn't get to the bears. And then I finally got to the bear slide. And then we just kept talking. We didn't talk about the bears. So where, where do the bears come in? The bears come in because I don't know if, if, you know, kids everywhere are the same. I suspect they are. But mine will not turn off the television.  And so eventually I slightly snapped. And I told them that if they left the TV on when they weren't using it, they were a polar bear murderer. So it wasn't one of my proudest parenting moments. I don't necessarily recommend that as a communication technique because they were slightly traumatized. But it definitely is true that, you know, maybe not that specific thing, but it is true that, that we have a climate situation and that as IT, we definitely have a part to play in the problem, but then also in the solution. Because we tend to think of, you know, sort of flying as, is super bad for the environment, but data centers use about the same amount of energy as flying. And so we need to be thinking about how we can reduce that energy usage. And so when, when we're doing performance optimization, that is almost always also carbon optimization. So going back to that framework about leading and lagging indicators, the, the carbon is the lagging indicator. That is the thing we care about. Carbon is hard to measure, but there are some leading indicators that are easier to measure. So cost is a leading indicator for carbon, and performance is a leading indicator for carbon. And I want to just give like a case study of, of what we saw when we measured carbon with quarkus, just to sort of see how, how those leading and lagging indicators work. So when we wanted to look at the carbon impact of quarkus, we didn't have, we didn't have the measurements, but we did have an older experiment that we done where we looked at the cost impact of framework choice. And so we could see, you know, that if you run quarkus, you can run in a, on the cloud, you can run in a smaller instance. And so then that means that your cost per month is much lower. My colleague, Clemall, he did this experiment and he wanted to really set it up as like a real world experiment. So instead of doing like a microbenchmark, he had it running for 20 days and then he got his cloud bill and that was the end of that experiment. But we were able to, from, from that, using some data sets that allow you to map from your instance and your region to your carbon, we were then able to get, you know, an estimate, but a pretty good estimate for the carbon impact. And we could see that again, you know, with quarkus, your cost was about a third and your carbon was about half of what it would be if you were using another framework. So it's, you know, it's not a perfect correlation, but it's a pretty strong correlation and lowering your cost reduces your carbon. And so this, this correlation, it's called the economic model. And so it tells you that the cost and carbon metrics are, you know, going in the same direction. But we wanted to do some more precise experiments that didn't rely on this data set. So we did it on-prem because then we had access to the full instrumentation to allow us to measure energy. And we, we looked at quarkus on JVM, quarkus on native, the other framework on JVM and the other framework as a native application. And on this, the lower lines are better. So quarkus on JVM has the lowest carbon. And the other thing to note on this chart is that, like some of the lines add to before the others, the shorter lines are, they sort of, that's where the throughput maxed out. So like on native with the legacy framework, we could not get above, you know, 9,000 transactions per second or something. So, so you can really see that the length of the line is a really good measurement of the throughput. And you can see that there's a gain that really strong correlation that we thought native would have a lower carbon footprint than JVM. But because native has that lower throughput, it actually had a higher carbon footprint.  The shorter line is the lower footprint. And there's the correlation. And so I've called this the Vroom model. And in hindsight, this was a really terrible name because the SEO of Vroom is awful. And so every now and then, you know, people will come to my website and they'll try and look up the Vroom model. And because it's got a nondeterministic number of Rs and a nondeterministic number of O's, they can't find it, which I've sort of slightly fixed now, but it took me a while. So naming is the hardest problem in computer science. But the takeaway is that Quarkus on JVM, it has the smallest carbon footprint because it has the highest throughput. There's this really nice correlation, which is good because we want to use the thing with the highest throughput anyway. So, I mean, just as a general principle, right, we shouldn't be wasting electricity, we shouldn't be wasting hardware. And so if we do the performance optimization to not waste these things, then that makes us overall good. So, you know, I think optimization is something that all of us can do and should do. And it can be really entertaining when you do your optimization and be guided by measurement. And optimization does have a cost, so only optimize what matters. Don't get sucked into the micro-optimizations. And with that, I think we've got, well, in fact, we don't have any time for questions. You went way over, but we can have some questions anyway. That's great stuff in this presentation, like multiple things that I think I have takeaways here. So really cool. I think we'll jump in and chat some things. One from Holly, maybe, that's an older video just from a few months ago on sustainability. And another one from our friend Marcus Eisley over in Germany on sustainability. Yeah, he's been doing some really good writing on the subject. Yeah. And Holly, my wife bought me a book with that title, Naming Things the Hardest Thing in Software Engineering, because I helped her do some code a while back and she didn't like the way I named things. It is completely the hardest problem. Sorry. So thank you very much. If there's any other questions, we'll find you. And everyone has access to Jeremy and I's email. So I think that they can send us something if they need to. So thank you for... Yes, thanks for chatting. And yeah, thank you very much. Really, really great talk today. So thank you. My pleasure. And we'll tweet and post our social media when we have a recording up available. So thanks for joining us and happy new year.


We're in the practice room right now. I thought it would be cool if I showed you guys how to practice, how to practice really efficiently. See, I'm a professional. So the way that I practice is the way that probably you could practice as well. So what I brought, I brought a cameraman in for the duration of my practice session today, just to be a fly on the wall so that you can see what it's like for a professional to practice efficiently. The really the important thing is just how many hours you log. You're not a serious musician unless you're logging at least seven hours a day. And you're not gonna ever be a professional on any level unless you're logging at least 16. So I try to do somewhere in the middle. If I can spend like 12 hours or something, that's like a good day. Now as you can see, I have the drum set in here. This is my drum set. Even though the drum set's here, really the key is that you don't wanna become distracted. Distractions are the key to not ever making progress in the practice room. So be sure to minimize your distractions. All right guys, so I'm gonna get to it. So you guys just chill over there and watch me work. Oh sweet, a new bird video. Are you still filming? Yeah dude, I've been in here since like 10 o'clock this morning, I'm going on hour number seven, bro. Listen, I know it's just, I just need some money for groceries. No, I know I have a meal plan, but like nobody goes to the dining hall. And plus I just got an air fryer. Do you know what you can cook in an air fryer? Mom, come on. How did this get so dusty? I think I have like extra muscles on my fingers. Yeah, you know, it's just, sometimes when the instrument is not up to par, it's like really difficult to get much done just because it just holds you back. Call me for weddings. Okay guys, so as you can see that's, I really can't keep going today because I just, I need to get a new keyboard before it makes sense to do all 10 or 40 hours a day. That's like a joke from, there's another channel that's really cool that people will get. Yeah guys. What? I'm just pretty sure you're keeping all of this.


And then the Keto brands don't appeal to me. I think this is your story. They're like very, for buying larger. This is your space. Yeah. That's it. So it's sort of like blending this world of how can we. I love that. How can we bring, in this case, high protein, low carb offerings to the natural foods consumer? I think we just made your tagline, at least in my head. I'm sure you've already thought about that a million times, but for me listening, I'm like,


We have been discussing the properties of waveguides as we have seen that waveguides are essentially conduits through which electromagnetic energy is transmitted from one point to another. And so, we had earlier discussed a waveguide which was basically two semi-infinite metallic planes. Today, we will be discussing initially the rectangular waveguides which we introduced last time. So, it is basically one of the dimensions is still infinite, but otherwise we have two dimensions namely it is a rectangular parallel pipe of infinite length cross section being a by b in the x and y direction and z direction is the direction in which the wave would propagate. We had seen that the Maxwell's equations which we had I will just illustrate one of them which was essentially for example, del cross of e equal to minus well d b by d t, but I will write it as minus mu d h by d t. There are no currents or sources no displacement currents del cross h as there are no currents. So, there is no current term here is epsilon d e by d t and what we are going to do is to take as before the time dependence as e or h they go as e to the power i omega t. As a result this d b by d t that gives you that results in essentially a multiplication by i times omega. So, as a result you can see the first equation here which is essentially this equation because this became minus i omega times mu times h. So, if you take its x components it will become del cross is x components and del cross is x component is as you can see here d by d y of e z minus d by d z of e y, but we have seen that since the propagation direction is z direction. So, d by d z essentially means multiplication by minus gamma because the propagation goes as e to the power minus gamma z. And so therefore, this equation became d by d y of e z plus gamma times e y is this. And similarly this is our Faraday's law where well this is this was Faraday's law and this is the ampere Maxwell's law. So, this is del cross h x component which is d by d y of h z minus d by d z which is same as plus gamma times h y is i omega epsilon e x and I have written down essentially all the six equations six components three components of magnetic field and three components of the electric field in this transparency. Now, so what we want to do essentially is to realize that these six equations I can cast them such that every component. So, I have six components. So, I will choose any two components for example, I will choose e z and h z and I can manipulate these equations to write them each component explicitly in terms of the z component of e and h only. So, we had talked about it last time, but let us go through it again. So, this equation which we talked about for example, the x component of the electric field i omega epsilon e x this is this equation and that is del cross h x component and which is as we have seen x component meaning d by d y of h z and d by d z minus d by d z which is plus gamma h y and plus d by d y of h z. So, what I do next is this that this h y which can come from here that is the y component of this I will write it. So, I already have a gamma and you can see that if I take y component of this equation I will essentially get I divide it by 1 over i omega mu and y component means d by d z of e x minus d by d x of e z and therefore, this equation becomes gamma by i omega mu times e x plus d by d x of e z plus d by d y of h z and now what I do is this that there is I have this x e x there and that I write down again by writing down what is this. So, you write notice that I can write this e x in terms of for example, I can eliminate e x from these two equations and write them in terms of the other components. So, if you do all that then it turns out if you do all that this is a bit of an algebra, but fairly straight forward that you can write e x in terms of the derivative of e z and h z. So, I have chosen for no particular reason, but because of the fact that the z component z direction is my direction of propagation I have written e x in terms of derivative of e z and derivative of h z and if you simplified all this is the way the equation works out where k square is gamma square plus omega square mu epsilon. This is and this you can do for each one of the other components that is e y h x and h y and this gives you a complete list of the equations where e x e y h x and h y are written in terms of the derivatives of e z and h z only and other than omega epsilon and mu which are of course, there we have one quantity there which is k square which is appearing as gamma square plus omega square mu epsilon. So, this is the set of equations. Now, what I will do now is this that now decide the following that we define what are called modes of propagation. Now, this is done by selecting or rather classifying these solutions in terms of such propagations for which this z component of electric field is equal to 0 that is one group z component being the direction of propagation if z component of electric field namely e z becomes equal to 0 it means that the electric field is transverse. So, this is called transverse electric solution T e we have seen this earlier also and similarly another group would be T z T m namely transverse magnetic field for which the h z is equal to 0 and e z is not equal to 0 and we had seen earlier that in case of the parallel plate wave guides there are also very special solutions for which both e z and h z were equal to 0 and this we called as the transverse electromagnetic or T e m mode, but we will see that that was a rather special case in case of parallel plate wave guides, but in this case we do not have such a situation. So, coming back to our equation the equation that we had for the components of the electric field that is the Helmholtz equation was basically d square by d x square plus d square by d y square plus d square by d z square which is nothing but gamma square times your any component of the electric field actually it is minus gamma square because e to the power let us write it as gamma square because e to the power minus gamma z we have taken, but if this is propagating actually this will be i beta. So, therefore, it will come to the other side and that any component let us say e alpha that is equal to minus omega square mu epsilon times the same component this was the equation that we had. So, as a result what you are getting is this that if you bring this to that side you find I get d square by d x square plus d u square by d s d y square plus gamma square plus omega square mu epsilon if you recall this we had defined as k square. So, therefore, this is k square times any component of electric field, but we are interested in let us say we are talking about T e mode for which e z is equal to 0. So, every solution can be written in terms of h z only. So, this quantity is equal to 0 and h z because z direction is basically infinite. So, the only dependence it can have is on x y and that quantity is equal to 0. So, this is the equation for which we need a solution. So, what we said is that you can solve this equation by what is known as separation of variable. So, h z of x y you write it as some quantity x which depends upon x only and some quantity y which depends upon y only.  So, what you find is y times d square x by d x square plus x times d square y by d y square plus k square times x y that is equal to 0.  Now, we are going to do this technique incidentally is known as separation of variable. So, you notice one thing that I can write this equation as equal to 1 over x d square x by d x square plus k square is equal to minus 1 over y d square y by d y square. Now, notice one thing this quantity depends upon x only this quantity depends upon y only and you want for whatever x and y these two must always be equal. Now, obviously this is possible if each one of them is a constant and let us call that constant as equal to k y square. So, this plus this is equal to that is equal to k y square. Now, so as a result you notice that these equations are well known equations to us for instance this equation is familiar to us in simple harmonic motion because this tells me d square y by d y square plus k y square y is equal to 0. So, as a result my solution for x and y now and the same thing is true for this quantity also what you could do is you could define a quantity which is k x square which is such that it is equal to k square minus k y square. So, as a result both of them have the same structure and my solution to these equations then become x is some constant c 1 cosine k x x plus c 2 cosine k x x and likewise capital Y is c 3 cosine k x x plus c 4 sin sorry yeah this is k y y and this is sin k y y. So, my total solution is a product of this with this in other words this is a product of terms like cosine cosine cosine sin cosine and sin sin. So, this is this is what I have got now and as we have seen that k square is equal to k x square plus k y square. So, once I have got this equation. So, I am writing down solution to my h z h z because we have taken T e mode. So, e z is equal to 0. So, h z is essentially a function of this into this. Now, let us look at how to determine some of these things the thing that you have to realize is this that if you take for example, go back to the picture of the rectangular parallel pipe. So, notice this is the z direction is infinite and so here I have got the x y plane for example, x is equal to 0 here. Now, these planes namely x is equal to 0 x is equal to a y is equal to 0 y is equal to a on these surfaces my tangential component of the electric field must be equal to 0 and notice this that my tangential components will be related to or will be equal to the e x or e y because I have got these surfaces for example, this surface is in the x y plane and so therefore, this is at z equal to 0. So, let us look at what does it give me. .. So, take for example, e x now e x is the electric field which is essentially the tangential component of the electric field at y is equal to 0 and at y is equal to b. Now, if you looked up the set of equations that we had written down the e x for the T e mode namely if e z is equal to 0 works out to some constant d by d y of h z. Now, remember this quantity has to be equal to 0 for y is equal to 0 as well as y equal to b. What it implies is at y equal to 0 and y is equal to b my derivative of h z with respect to y must be equal to 0. Remember that my h z is a function of consist of four terms cosine k x x cosine k y y cosine k x x into sine k y y etcetera. Now, if you want the derivative of h z with respect to y to become equal to 0. So, it goes back here. So, my let me write down what is x into y which is my h z this is c 1 cosine k x x into c 3 cosine k y y plus c 1 cosine k x x c 4 sine k y y plus c 2 into c 3 sine k x x cosine k y y plus c 2 into c 4 sine k x x into sine k y y. Now, let us look at what are we trying to say. We are saying that derivative of this derivative of this with respect to y should be 0. Now, if you are differentiating with respect to y this term for instance will give you k y sine k y y. This term will give you k y cos k y y and like this. Now, I want that for y is equal to 0 this term should give me 0. So, that now this has become sine k y y. So, I do not have a problem with this term becoming equal to 0. Now, so what am I actually left with you notice that the term that I must have this will tell me that I must have c 3 into c 1 this term must become equal to 0 etcetera. Now, if you do that then ultimately you are left with because these are the four conditions to be satisfied. Ultimately, you are left with that I can have h z only given in terms of this type of an equation that is c times cosine m pi by a times x times cosine n pi by b times y. Remember, my boundary conditions are that the tangential component of the electric field which come as such derivatives of h z and the normal component of the magnetic field they will be 0 on the plates. So, that tells me that h z is just a product of cosine into cosine and these facts that the k x and k y becoming equal to m pi by a and n pi by b is because I want these electric fields to vanish at x is equal to a as well as y is equal to b. So, as a result if you now want to write down your full equations h z which is a function of x y z is this solution which you have just now obtained times e to the power minus gamma z and k square which we had seen is omega square mu epsilon plus gamma square k square is k x square which is m pi by a whole square and plus k y square which is n pi by b whole square. So, these are my solutions for h z and e z is equal to 0. So, I will just leave this transparency for some time this tells you that once you have got h z of z you can obtain e x e y h x and h y purely in terms of the h z. So, these are the things which are there. So, as we have seen k square is this quantity and this is what it is. Now, if you look at gamma now gamma is given by m pi by a whole square plus n pi by b whole square minus omega square mu epsilon. Now, this tells me now you remember that my propagation went as e to the power minus gamma z and we have seen that gamma is given by root of m pi by a whole square plus n pi by b whole square minus omega square mu epsilon. Now, in order that this may be a propagating solution I want gamma to be imaginary otherwise it is an attenuating solution. Now, in order that gamma is imaginary it tells me there is a minimum frequency omega c given by well you want omega square mu epsilon to be greater than this. So, omega c is given by 1 over mu epsilon time square root of m pi by a whole square plus n pi by b whole square and of course. So, this if you like is my cutoff frequency what I have written down here is the this was of course, your angular frequency and this is the normal f c which is omega c by 2 pi. So, this is a minimum cutoff this is a cutoff frequency for t e m n mode. Now, notice that if you take for instance t e 1 0 mode. So, m is equal to 1 n is equal to 0 and this depending upon which one you call to what this is what is known as a dominant mode because this is the this is the mode for which the frequency is minimum whether it is t 1 0 or it could be t 0 1 it would depend upon which one of these dimensions is smaller or bigger and. So, therefore, that is the cutoff frequency and likewise you could work with e z that is h z equal to 0 transverse magnetic mode and e z is not equal to 0 and if you did exactly the same algebra as we talked about earlier you find that for this t m mode e z works out to be a product of sin into sin. Now, notice because this is product of 2 sin function unlike the t e mode which was the product of 2 cosine function I cannot have m or n to be equal to 0 because if it is then e z will be equal to 0. Now, I did not have that problem with the cosine function there all that I required is both m and n should not be 0 because if they were then that would be a constant, but in this case if either m or n becomes equal to 0 e z vanishes and once e z vanishes since h z is equal to 0 all my components would trivially vanishes. So, because of that the t m mode has a higher cutoff frequency than that of t e mode and hence t e mode is known as the dominant mode. So, let us look at the some minor properties supposing there is propagation again we are back to both it could be this will be valid for both t e as well as t m mode. So, when there is a cutoff when the frequency is above the cutoff the propagation vector beta which is the same as i beta being equal to gamma is simply square root of omega square mu epsilon minus m pi by a whole square minus n pi by b whole square and we define omega c as 1 over root of mu epsilon by into square root of this quantity. So, that beta can be written as root mu epsilon omega square minus omega c square raise to the power half and omega is greater than omega c for in order that propagation may take place. Now, if you have this so beta is your propagation vector. Now, remember that the group velocity of the wave is given by d omega by d beta where I am already seen what is the relationship between omega and beta which is gives me 1 over root mu epsilon incidentally this quantity is nothing but the velocity of light if it is in vacuum multiplied by 1 minus omega square by c square. But the phase velocity this of course is less than the speed of light in vacuum as it ought to be, but the phase velocity which is simply omega by beta is given by this expression namely c by square root of 1 minus omega c square omega square. Now, if you take the product of the group velocity with the phase velocity that gives you 1 over mu epsilon and if you are dealing with vacuum between the plates then it is just equal to c square. Notice one thing that in case of a T e mode if you took the ratio of e x to h y if you recall when we talked about the propagation of uniform waves in free space we had seen the ratio of e x to h y was nothing but what we called as the characteristic impedance. Now, here also something very similar works out e x by h y is i omega mu by gamma and we have seen gamma is i beta. So, it is omega mu by beta and by substituting for beta you get this is equal to omega mu by root mu epsilon into this factor here and this is what you denote as eta T e which means it is the characteristic impedance corresponding to the T e mode. So, e x by h y works out to eta T e and because of the directions e y by h x also works out in magnitude to be eta T e, but is given by minus eta T e. Now, let us look at the power transmission in the mode. So, we have seen that what we are looking for is transmission of power which is designated by the pointing vector. Pointing vector in terms of complex electric and real field magnetic field is given by half of real part of e cross h star and just now we have seen that e x and h y's are related by this eta factor. So, therefore, I can write the h as or e. So, here what I have got e cross h star real part and you remember I am in T e mode. So, my z component is 0. So, as a result the remaining components are given by e x h y star minus e y h x star. What I have not written here is that because the direction of propagation is along the z direction. So, I have essentially taken the z component of e cross h star and if you now write down that h y by e x is eta eta T e. So, you get e x square plus e y square divided by 2 eta. So, this is my average pointing vector and the power that is transmitted is since the z direction is the direction of propagation it flows through at any point of time through x y plane. So, therefore, you have to take the pointing vector and average pointing vector and integrate it from d x d y x going from 0 to a and y going from 0 to b. And if you do that this is the expression because you have to substitute the expressions for e x and e y and do this integration. And supposing you had a lossy waveguide. Now, if you had a lossy waveguide then we have seen that gamma will not become imaginary, but gamma will become real. And by designating its real part as alpha we get this quantity to be proportional because there is an e and there is an h to e to the power minus 2 alpha z. So, that is the rate at which the power would attain it. We will come back to this point a little later. So, if you look at what we said just now the power transmission is given by this expression the you have to these are the two terms. And you can do this integrations because they are fairly straight forward cosine square and sine square terms. Just if you do the integration each one of them will give you a by this will give you a by 2 this will give you b by 2. And so therefore, this is the way they will work out. So, this is the expression for the power transmission. Having talked about rectangular parallel piped waveguide I am going to now close the remaining sides as well. That is what I have got is what is known as a rectangular cavity. So, I have got electromagnetic waves which are confined within the boundaries of a rectangular parallel piped. I have taken the dimensions to be a b and d I have not taken a b and c because c is the velocity of light I do not want any confusion. So, I have taken this is what is known as a resonating cavity. This is very similar to for example, like an L C circuit. We will see just as L C circuit is used to store electrical energy a resonating cavity is used to store electromagnetic energy. The typical resonating circuits however, have a great advantage over the L C circuits because these have frequencies upward of a few 100 megahertz and they turn out to be less lossy than L C circuit. Now, remember when you talked about the parallel piped rectangular waveguides we had not talked about losses at all, but we know that losses are facts of life. So, therefore, we have to worry about losses you can minimize it, but we will be talking about it as you go along. The technique of discussing the resonant cavity is very similar to what we did. . So, let us first look at the wave equation remember we had said del square e any component e alpha x y or z is given by minus omega square mu epsilon e alpha. So, what you do is this now this is the equation which we need to solve del square is d x s d by d x square plus d by d y square plus d by d z square. Now, I will use the same technique namely the technique of separation of variable by assuming that this e alpha remember my alpha can be x y or z component whichever fancies me. This is written as a product of capital x which is a function of x only, capital y which is a function of y only and capital z which is a function of z only and what I do is exactly what we did earlier. So, if you write down this is d square by d x square of e alpha which is x y z. So, this gives me x of x multiplied by y z plus d square by d y square of y multiplied by x z plus d square by d z square z multiplied by x y this is equal to minus omega square mu epsilon into x into y into z.  So, what we do is this now we exactly work the same way as we did earlier this is a function of x only this is a function of y only this is a function of z only these three things must be added in such a way that for all values of x y and z it must give me a constant. Now, obviously that is a tall order unless this is a constant this is a constant and this is a constant and these three constants added together gives me the third constant. Now, so what I require is d square x by d x square that is equal to a constant. So, let me write it as a minus k x square times x then d square y by d y square equal to minus k y square times y d square z by d z square is equal to minus k z square z.  So, that this equation will be satisfied if I have k x square plus k y square plus k z square is equal to omega square mu epsilon this is the technique of separation of variable. The advantage is if you look at any one of these equations these are equations which are known to us in solution of simple harmonic motion. So, that they all give me linear combination of the sum of x and cos k x x sin k x x etcetera that is supposing I am writing e alpha. So, I have got this term which is my capital x which is a alpha cos k x x plus b alpha sin k x x and similarly y and similarly z. Now, what do you do from here the what I do now is this I now know that I have a rectangular parallel pipe. So, therefore, my x component for instance will be equal to 0 either when y is 0 or d because that is one plane on which my x component of x direction is the tangential direction or z is equal to 0 and z is equal to d. So, e x of x y z let me illustrate this here is equal to 0 for y is equal to 0 y is equal to b z is equal to 0 and z is equal to d. Now, look at what it means if I want this quantity to be equal to 0 for y is equal to 0 now substitute y is equal to 0 here. So, this term automatically goes away this term automatically goes away and I am left with x cos k x. So, c alpha cos k y y remains now the. So, this term will become 0 and I will have c alpha cos k y y now I want that to be 0 for all values all for y is equal to b as well. Now, if I do that then that tells me that my k y must take values m pi by b because then only this term will become equal to 0. I cannot have both c is equal to d 0 d is equal to 0 simultaneously because if I did then the entire e alpha will go away and likewise you substitute that this field must become equal to 0 for z is equal to 0 which will make this term go away and as a result my e alpha term must be equal to 0 and then for z is equal to d. So, if you put that then I get e alpha this term remains and from these two only the sin k y y and sin k z z remains and the factor d alpha into f alpha I have combined it into one constant which is e x 0. So, this is my structure of e x with m becoming equal to plus minus 1 plus minus 2 etcetera. So, that is e x x now likewise I go to e y and well the argument is essentially the same the just as you got when you had e x you got sin k y y and sin k z z and the x part had both the terms here also I will get since it is a e y the y part will have cosine and sin the x parts will have only sin and k x will be l pi by a k z will be equal to n pi by d and likewise for e z as well. Now, how do you proceed from here? Now, notice that irrespective of my solutions my del dot of e must be equal to 0 del dot of e is d by d x of e x plus d by d y of e y plus d by d z of e z since I have already obtained e x e y and e z what I require is that simply differentiate.  So, this is what you get this is first term is obtained by differentiating with respect to x the second term differentiating with respect to y the third term differentiating with respect to z. Now, unlike e which must be equal to 0 the tangential component must be equal to 0 at the boundaries my del dot of e must be equal to 0 anywhere for any value of x y z my del dot of e must be equal to 0. Now, so what you do is for instance look at this equation try to satisfy this del dot of e equal to 0 at for instance try to satisfy it at x is equal to 0. Now, if your x is equal to 0 let me first dispose of the last two terms if x is equal to 0 these two terms go away. Remember I have said this relationship is valid at all values of x y z in particular for x equal to 0 and whatever y z you prefer. So, when I put x equal to 0 these two terms go away, but if I put x equal to 0 I am left with b x cos k x x sin k y y sin k z z b x is a constant which can come here. So, this is what I am left with. Now, identically what you do is this for example, so that get me a d y equal to 0 and you can again do this for y is equal to 0 x and z arbitrary z is equal to 0 x and y arbitrary. If you do that one by one one of these terms constants will go away and you will be left with terms of this type x component cos k x x the two others are sin y components cos k y y the two other things are sin z components cos k z z two other things are sin and k x is l pi by a k y is m pi by b k z is n pi by d. Notice that I cannot have l m and n becoming simultaneously 0 that is not permitted, because if I did then this e will trivially go become 0, because at x equal to b for example, y equal to b this will make sin k y y equal to 0. So, these integers cannot be simultaneously 0. So, I write down del dot of e is equal to 0 since all of them are of sin, because this is my e. So, when I do del dot of e I get d by d x will give me a sin. So, this is the way it will be that all the signs are common I get e x 0 k x e y 0 k y e y 0 k k z this is wrongly written. Now, this equation has to be valid for all values of x y and z inside the cavity. As a result this tells me e x k x plus e y k y plus e z k z this is to be corrected is equal to 0. So, let me write it down since that equation is slightly wrongly written. So, I must have e x 0 k x plus e y 0 k y plus e z 0 k z since e x e y e z 0s are e x 0 e y 0 e z 0s are the magnitudes of the components of the electric vector k x k y and k z are components of the propagation vector. This equation simply tells me that the electric field direction is perpendicular to the direction of the propagation vector. Returning back to the wave equation I had del square of e. So, del square is d square by d x square plus d square by d y square plus d square by d z square this quantity is equal to minus omega square mu epsilon. Remember in each of the components take any component I have to differentiate only the cosine part twice. So, I get k x square plus k y square plus k z square equal to omega square mu epsilon and of course, I know that k x is equal to l pi by a. So, it is l square pi square by a square plus m square pi square by b square plus n square pi square by d square is equal to omega square supposing I am in vacuum then omega square by c square. So, this is what I have got. Now, like we classified the waves in a rectangular waveguide or in a infinite semi infinite waveguide it is possible to talk about the classification in terms of T e and T m mode as well. Generally conventionally the longer direction will be considered to be the propagation direction but of course, it really is not particularly important here. So, if I take E z is equal to 0 which is my T e mode. So, the I will label the modes by T e l m n. Now, let in this case since it is T e my E z is equal to 0 which implies that E z 0 is equal to 0 and this implies that E x 0 k x plus E y 0 k y is equal to 0 this is because E dot k is equal to 0. So, I am left with now E x and E y. So, E x I have written now E x 0 cos k x x E y is E y 0 cos k y y the other two components are sign and you can now determine the corresponding H components the components of the magnetic field H x this is once your E z is 0 you can write them down and these are the expressions for the H x H y and H z. So, this is fairly standard just a differentiation and you can just look at it and work it out yourself. . Let me now specialize it to a particular mode supposing I am working out with a T e 1 0 1 mode that is l is equal to 1 m is equal to 0 and n is equal to 1 just going back a little bit you notice that if m is equal to 0 then by E x becomes equal to 0. So, the only component of electric field that survives is E y which will be given by E y 0 sin k x x this term is 1 and into sin k z z. So, I have written that down that you have got E x is equal to 0 and normally it is conventional to write the T e 1 0 1 mode in terms of the H z 0 that is the amplitude of H z which is the one which determines the T e 1 0 1 mode. So, for example, H z is this quantity here. So, this quantity here remember k y is equal to 0. So, this quantity here E y 0 k x by minus i omega mu will be designated as H z 0. So, this is what I have done here. Now, if you plug this in then I will write H z as equal to H z 0 cos k x x sin k z z the y thing is not there and using my standard equations relating the E y and H x to H z I can write E y and H x like this H y which again has a proportionality with sin k y y is equal to 0 because k y is equal to 0. So, this gives me the modes the fields for 1 0 1. Now, the next thing that we need to do is to find out an expression for the loss in case of the resonating waveguides. This is called resonating because you notice that because of this relationship that we had that omega square mu epsilon is given by this. The omegas that are permitted are very specified frequencies. See in the rectangular parallel pipe waveguide that we had where z direction was the direction of propagation. We had seen that there was a minimum frequency above which the propagation took place. In this case however, there are specified frequencies at which the propagation will take place depending upon the mode that you have got because omega square mu epsilon is l square pi square by a square plus m square pi square by b square plus n square pi square by b square. Once you have fixed l m and n the omega m take only specified values and because of that we call it resonating modes because unlike the other 2 waveguides that we had talked about. In this case there is no cut-off frequency above which the propagation takes place. There are frequencies at which the propagation takes place. So, let us look at this. . So, as I said in the beginning the purpose of a resonating cavity is to provide a mechanism for storing electromagnetic energy. However, in principle though we have said that my walls are perfectly conducting the there would be losses in the dielectric. So, with every cycle by cycle I mean supposing my z direction is taken as a propagation direction. So, my way would proceed towards z is equal to d come back to z equal to 0. So, with every cycle a certain amount of loss will be there. Now, what I do is this I define the quality factor which is also known as the Q factor of a cavity as the ratio of the energy that is stored in the cavity to the amount of energy that is lost through the walls of the cavity every cycle. So, that is defined as the Q. Now, how do I calculate this Q? I will just begin a calculation today and we will try to complete it next time. So, first is you notice the numerator. The numerator is the amount of energy that is stored in the cavity. Now, we had seen that the average energy that is stored in a electromagnetic field is given by epsilon by 2 e square. There is an additional 1 over 2 has come in because of my time factor the sin square omega t cos square omega t average. So, it is epsilon by 2 and you integrate over the volume of e square d v. Now, I am in T e mode, e z is equal to 0, e x was automatically equal to 0. So, therefore, I have got simply e y square to take care of. If you put in the expression for e y square which is written in terms of h z 0 you will notice that e y is product of sin k x x and sin k z z. So, I have got sin square k x x sin square k z z. So, the d y integration gave me a b and these integrations you can easily do by writing sin square in terms of cosine 2 sin sin square theta in terms of cosine 2 theta and integrating this out. Now, if you integrate that out you get the amount of energy that is stored to be given by this. The next question is what does one do to calculate the amount of loss? So, first thing that we realize is the losses must take place through the walls of the cavity. Now, I assume that the walls are made of good conductors. Now, if the walls are made of good conductors then the skin depth that is the depth to which the fields penetrate will be small the skin depth is low. Now, if the skin depth is small I can assume the field in these is the same as the field on the surfaces of these conductors conducting boundaries. So, I also know that if I have a tangential component of the magnetic field that gives me a surface current. It is this surface current which I will need to calculate on each of the six faces and once I know what is the resistance of each one of these faces I simply calculate how much is the joule loss on each of these faces. This is a calculation which I will leave for the next lecture.


This video is all about how to be successful as a life insurance agent.  You will struggle to succeed tip number two Once you have prospects, I don't care if you have to buy leads. You must have prospects Once you have that down tip number two is you must run appointments I recommend that a new life insurance agent run 15 at least set 15 appointments every single week It sounds like a lot, but I promise you if you set 15 you'll run 10 and you'll end up right in five I mean you'll have a you'll have a few stand you up It's just the part of the numbers you have to have appointments set 15 tip number three Then it's all about consistency Repeat the process that got you where you are you want to make a hundred K You want to make a quarter of a million dollars You want to make a half a million dollars in this business do these three steps in that order And follow number three and be consistent weekend and week out I'm Cody the strange mentor if you got value from this video and you want to continue to follow us click subscribe Give us a like make sure that you're in tune with what we're doing because I promise you If you love this video, you'll love all of our videos