در حال بارگذاری ...

Benchmarking Blade Components0:00

(upbeat music) Okay, we saw how Blaze takes a slow blade page and makes it fast, but let's answer the question of why is blade slow in the first place, right? Like you gotta be asking yourself that. I'm extremely curious, so let's figure it out. I have this benchmark file, it's a normal blade view with a 25,000 iteration loop, and I'm rendering a button component 25,000 times. Here it is in the browser, 25,000 just button elements,

and I'm rendering a button component 25,000 times. Here it is in the browser, 25,000 just button elements, and then the source of that component right here is pretty simple, props, some class assembling, putting those inside of an attribute bag to forward attributes and merge them, echoing out a slot. So this is your average button component in my opinion, and we render it 25,000 times, and I wanna know how long does it take?

and we render it 25,000 times, and I wanna know how long does it take? So I have this little terminal utility down here that detects when this file changes or this file, and runs that benchmark like maybe five or 10 times and takes the average speed and spits it out so that we can get a more stable benchmark. So I'm gonna hit save and we're gonna learn how long it takes for blade, Laravel, whatever, to render a single button component 25,000 times.

for blade, Laravel, whatever, to render a single button component 25,000 times. Let's take a look. Okay, 200 milliseconds, okay, interesting. So that's our starting point, it's 200 milliseconds. It's kinda arbitrary 'cause there's 25,000 buttons, and I don't know, but what matters is we have a baseline now of a full button component, that's how long it takes. So the first thing that I'm curious about

Testing Bare HTML Render1:29

that's how long it takes. So the first thing that I'm curious about is what happens if I get rid of all of this and just simply render a button element with nothing else? How long does that take? 'Cause this is gonna show us what is the actual just blade portion of that, not all the extra stuff I had going on. So let's take a look at that and see. 82 milliseconds, so okay,

So let's take a look at that and see. 82 milliseconds, so okay, clearly there is, we'll just call it 80. Clearly there's a lot going on, like we've more than doubled or halved the speed of it just by removing all of that stuff, which I guess kind of makes sense, but I thought in my head that this would actually be lower. So I was surprised to learn that 80 milliseconds are still being taken up just by pure blade overhead,

Finding Performance Culprits2:04

So I was surprised to learn that 80 milliseconds are still being taken up just by pure blade overhead, and I'm saving you the whole journey, but if you do go through and you remove specific pieces of this to figure out where everything is going, this is the biggest culprit is an attribute bag where you're merging classes, that's expensive, this is the next biggest culprit, and then after that, this stuff's cheap, whatever.

Comparing Include vs Component2:24

this is the next biggest culprit, and then after that, this stuff's cheap, whatever. So let's skip back, oh, what have I done? What have I continued to do? Let's skip back to whatever. There's our button element, okay? Bare component 80 milliseconds. Now the next question for me is, what about a normal blade include? Like instead of going through all of blade's

what about a normal blade include? Like instead of going through all of blade's component architecture where you have to have props and attributes and things, what if we bypass all that and just straight up include the file? So let's just include component stop button, okay? And we'll see how fast that is. 44 milliseconds, okay? Interesting, it's getting faster,

44 milliseconds, okay? Interesting, it's getting faster, so clearly like half of that speed was just blade doing stuff for components. And then the next thing I remember going, okay, I'd include, so that's how long it takes PHP to include a file 25,000 times, is 44 milliseconds. But let's just make sure, let's make sure that's the case. So to do that, we're gonna use a normal vanilla PHP require statement.

Testing PHP Require Speed3:23

So to do that, we're gonna use a normal vanilla PHP require statement. So we'll say require resource path views, resource path is gonna cost some anyway. We'll say views, components, button.blade.php, typing, and run this. And we see that's 12 milliseconds, okay? Interesting, that's pretty fast. I didn't know that @include was that much more expensive than just a normal require statement.

I didn't know that @include was that much more expensive than just a normal require statement. And then the final test, of course, is what happens if we just paste in the text itself, no requiring files at all. And there it is, three milliseconds. So there's a lot to kind of learn here, a few surprises for me, one surprise was require statements are pretty cheap. I thought they would be way more expensive.

are pretty cheap. I thought they would be way more expensive. I was extremely impressed that PHP can require a file 25,000 times. And it's only 12 milliseconds, that's crazy. I didn't know that @include had overhead. I thought it was just require under the hood. Clearly it's not, there's stuff going on. I kind of figured the blade components had a lot of extra stuff and they do.

I kind of figured the blade components had a lot of extra stuff and they do. And then in line, this is how long it takes for PHP to do a 25,000 iteration essentially. If we remove all of the white space, it's about the same speed. So that was another kind of realization as well. PHP is pretty freaking fast at looping. Are we allowed to say freaking on layer tests? Well, here we are.

Summarizing Results and Next Steps4:48

Are we allowed to say freaking on layer tests? Well, here we are. We're looping at 25,000 times and yeah. So what did we learn? It's hard to say we learned that that blade is slow because of death by 1,000 cuts. It's slow because of everything. There's all sorts of things hidden in here that are making it slow. And we don't even really know the answer to that question.

that are making it slow. And we don't even really know the answer to that question. So I think we need to peel back one more layer and look under the hood and see what is blade actually compiling this stuff to. What does that include under the hood? And why is that slow? It's a fun question to answer. And when we try to answer it, we will learn something fundamental about blade

And when we try to answer it, we will learn something fundamental about blade that will help you in all of your Laravel development. I promise it's one of the most important things to, I don't know, understand about Laravel when you're working in a day to day, especially with blade. So I'll see you there.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟