 I was going through optimizing the dimensions package when I noticed something a bit weird. A lot of the functions that are in generics.mathematics.dimensions specifically are very straightforward functions. Things that are there to basically hide the fact, hide some of the underlying stuff, but there's not really a whole lot going on in them. Operators, which if you look at the assembly, fundamentally just do what a basic operator does anyways, and tons of things that should be inlined. So I went through and added a bunch of inline always aspects, just to force that these should be inlined unless, for some reason, inline it would change the underlying semantics. And in that case it would give an error. But this essentially says that inlining is not preferred, but should be done. Something weird happens. Let's go through and make sure that these are built and installed. Okay, so like I said, inlining always is not always allowed. Let's change that. Just to inline. I'm trying to be a bit hyperbolic at first, and then just weaning down so that it can show, because you could show something, but these are fine too, inline always. Let's change these as are these. All right, I believe these, the unit constructors would be considered dispatching. So let's just make sure that this builds at this point. It should, and it does. And then just let it finish building, and then I'll go and install it. I'm going to go into tests and just make sure that these are, well I just installed new stuff, so it's got to be, they've all got to be rebuilt. I'm only showing the dimension stuff, so let's only build those. I normally don't do specific builds. I normally rebuild the whole thing, but really don't need to do that just to demonstrate what I noticed. Okay, now it's not the tests that I'm interested in, but actually the profile information. Now I don't have a whole lot written here, but those seem really high. Let's just compare. Something is definitely wrong here. Is this, is this that my approach is horribly inefficient now? I highly doubt it, because I've done this before and noticed almost no performance overhead. Something wrong with my slightly revised approach? I doubt that, but this is odd. Also, these numbers are higher than I was noticing before, even with this. That's change, end line always. Oh my god, there we go. To just end line. Look at that already. That's pretty hefty memory decrease. And obviously storage decrease as well, but these libraries get loaded into memory in their entirety. Just rebuild the dimension stuff again. Those numbers nearly halved. Just by not inlining them. Something that nearly everybody will tell you improves the performance. Actually halved at the execution time. Removing something that people tell you improves performance. Actually sped up performance. Let's see if we can push this further. Well, I broke the compiler. That's not the first time I've done that. Let's just remove all of them and then rebuild this. Because then we're telling it that inlining shouldn't even be preferred, and the compiler will only inline in cases where it can prove that there's no performance degradation. Which probably going to be pretty rare. Or maybe no change at all. Inlining preferred will still get undignored if it will cause an increase in execution time. Inline always forces it. That's the always name. I really only need to rebuild the profile, so let's just build that one specifically. So that's the same. And I'm not inlining anything here. So obviously something about my changes did increase the execution time quite a bit more than expected. Almost ten times more. I do need to deal with that. Before it was only about a 15% increase, so some things are going on that should not be. I'll look at the assembly to figure that out. But I figured one of the first things to do would start to inline the really simple stuff. And as you can see, that actually hurt the performance immensely. So then the question most people should be asking is why would inlining, generally regarded as totally viable optimization technique, decrease performance that much? And that's sort of an advanced topic, but there is something I would like to show you guys. This is likely going to get some unnecessary flak. I'm not trying to say object orientation is bad. There's just a few things here that you want to read because it's going to cover the point. Now these regard specifically with object oriented programming, but the issue that is causing the inlining to actually be slower is present here and is something that people need to be aware of with modern computers. Because a lot of the performance stuff for old computers does not translate well to new computers. So Kat V has a few things mentioned here, some of them are just bash object oriented programming specifically. A few of them do discuss what we're interested in and are one of the best sources that actually discuss what we're interested in. I would recommend reading all of these even if just for nothing else to gain some perspective. You see, go through my code, you can see that I do use objects. I'm not purely against object oriented programming, but it has its place and some people get a bit fanatical over it. The one we're going to be covering is that I really want you to read and that I'll show off a little bit as pitfalls of object oriented programming by Tolby Albrecht of Sony Computer Entertainment Europe. And I've already loaded that up. It's meant to be given as a presentation, but like most crappy presentations, there's considerably too much text and so this is readable in its own right. Again, I would strongly recommend actually going through and reading this and I will have links to these, both the KatV page on software and then also this presentation specifically. I'll have the KatV link rather than the Sony link just because the KatV link... KatV guys are really good at archiving, so this link hasn't changed in a decade. This is really where it starts to get interesting. There used to be a time where memory was faster than the processor, but it's totally reversed now and this keeps... like processor speeds are growing considerably faster than memory speeds and it's causing this little problem. Now this is back in 2009, so it's considerably worse of a difference now, but the ram latency is something people need to keep in mind. Any time you increase the memory, the size of the memory that something uses up, it's a huge amount of effort to actually... for the processor to actually read that memory as opposed to just calculating something and they'll have some great examples in here that I don't know where they are, but have nothing to do with object oriented programming specifically just like checking a condition where whether or not something exists and then calculating it because of things like branch mis-predictions, it's actually better to just calculate it and then not wind up meeting it or then of course they cover the... how reducing memory use and actually calculating things instead of having them in memory or things like preloading and what not, considerably improved performance. It's a great read on optimization and tons of this apply to even non-PlayStation 3 stuff for whatever reason he's actually largely talking about just computers in general and not the PS3. The inlining issue, you saw how much of a difference that had in the size of the overall library. That specific package, the library, the shared object, that is, did decrease by that specific amount, the 0.15 megabytes. That's what had the effect. It's just that massive increase in RAM that was used had that effect. So the point here is just be careful about inlining. Don't blindly inline thinking that things are going to be faster. Even I'm guilty of that but there are so many ways to measure the execution time of code that you should be doing it and compare specific functions whether it's actually advantageous to inline them or to not inline them because that'll surprise you. We'll just leave it at that. It'll surprise you. There are some things that should be really obvious that they should be inlined and as it turns out, no, they should not be inlined at all or some things that you would think should never be inlined actually do gain performance benefits from inlining them. So just be aware of that. It's a very complicated issue that has a lot to do with individual things with the processor that people tend to not even pay attention to. So yeah, always test, always profile your code because that's the only way to actually know this stuff. So hopefully you found this video helpful. If you have, give me a thumbs up. Hopefully you find my videos in general helpful or at least entertaining. Consider subscribing, you get notifications when I make new videos which happens to be quite often and you actually wind up helping me out by subscribing. Have a good one.