(upbeat music) All right, so in the last episode, we saw broadly where the slowness in Blaze comes from, but I wanna pop open the hood and look under it and find exactly where the slowness comes from. So let's do that. This benchmark file from before, I removed the 25,000 iteration loop. It's literally just rendering a button element. You know, we could put anything we want in here.

It's literally just rendering a button element. You know, we could put anything we want in here. Hello, whatever, and it shows up right there. Okay, got it? Now, to demonstrate this point a little more clearly, I'm gonna echo the current timestamp like this now, okay? So this is Blade. What you're seeing right here, this is not valid PHP syntax. This does not exist in PHP.

this is not valid PHP syntax. This does not exist in PHP. If we were using PHP, we would do echo now like that, right? But we're using Blade. But it runs in PHP. So somewhere along the line, Laravel has to convert this Blade into actual PHP that runs, right? Where does it do that? I think this is an extremely useful question to answer

Where does it do that? I think this is an extremely useful question to answer just as a Laravel developer in general, because I've found this knowledge to be just very useful in my working with the framework. Check this out. The view itself lives in resources, views right there, benchmark.play.php. However, if you drill down in storage, framework, views, and the only time you may have been inside storage

However, if you drill down in storage, framework, views, and the only time you may have been inside storage is maybe looking at your logs or something, but this is a directory that Laravel uses to put stuff. So storage, framework, views, you'll notice that there is a file here. Let me open this to the side, okay? And take a look at this file. This is like a mirror of the actual Blade file,

And take a look at this file. This is like a mirror of the actual Blade file, except it's converted into raw PHP. This is Blade's compiled file. Blade gets compiled from Blade syntax into raw PHP syntax. Every time you run Blade, this is something that I didn't understand. I thought that it did it in memory or something and only did this when you ran Artisan View Cache, but that's not true.

and only did this when you ran Artisan View Cache, but that's not true. It always creates these files anytime you're rendering any Blade. If you run PHP Artisan View Cache, it will just create all these files ahead of time instead of on the fly. But now that we have this file, we can kind of tinker with it like we could say hello. And now we just added hello without actually adding that

we can kind of tinker with it like we could say hello. And now we just added hello without actually adding that to this file itself. If we say world and we modify this file, you'll see that that one wins. This is the source of truth, this is the Blade file. But I just think that's kind of interesting and that like something to prove to you, just like to triple prove it to you, that this is the file that PHP is running, okay?

just like to triple prove it to you, that this is the file that PHP is running, okay? This is the actual thing that PHP hits. This is just the Blade that gets converted into that. And how does it know? So I just changed this and it let it run, which is interesting. How does it know when to recompile this? Like if I update this to say hello world, how does it know that this needs to be recompiled?

Like if I update this to say hello world, how does it know that this needs to be recompiled? It clearly works. Well, it uses file modified times. This is just a nugget for your own brain. Every file in a file system has a last modified timestamp and it compares these two. It goes, hey, is this file newer than this file? Then we need to recompile this file because this file has changed.

Then we need to recompile this file because this file has changed. That's how it works under the hood and a nutshell. So now that we know that, we can inspect these cache files or these compiled files anytime we want to see what is actually happening. So if we write back that includes, let's do include, what is it, component stop button, and then we save it, then we run it, you'll see that there it is.

and then we save it, then we run it, you'll see that there it is. Echo, ENV make component stop button, array diff key, get to find VAERS, data path, render, there it is. So what does that tell us? Well, I mean, it tells us that all of that extra overhead for include above require ones, that 30 milliseconds or something, is the cause of ENV make.

that 30 milliseconds or something, is the cause of ENV make. We're resolving a view inside Laravel, array diff key, that can't be cheap, and then render, that's not cheap either. So what about the blade component? Let's look at that. So now if we do X button and we render that, and then we, whoa, look at that. So it's no wonder that the component is twice as slow

and then we, whoa, look at that. So it's no wonder that the component is twice as slow as an include because look at all this stuff it has to do. It has to resolve an anonymous component with the view name right there, and data is set attributes instance of, the list goes on, should render, resolve view, more data, start component, render component, there's just a lot going on. This is why blade components are slow,

there's just a lot going on. This is why blade components are slow, and Blaze's job is to try to skip all of this stuff. But I wanted you to see it with your own bare eyes. I wanted you to A, know how blade compilation works, know where those compiled files live, and see why blade components are slow because of all of this stuff. Like what it actually gets rendered to, because this knowledge is really just gonna help you

Like what it actually gets rendered to, because this knowledge is really just gonna help you understand the need for Blaze and why the optimizations exist in the first place. So let's keep moving.