[11.x] Supercharge Blade

[assertchris]

Attempting to cement my legend status, by:

• Caching identical view renders
• Only dispatching events if there are listeners
• Inlining component props preparation steps
• Avoiding needless array → AttributeBag → Iterator → array conversations
• Caching known component constructor parameters for continuous exclusion

These changes focus on reducing engine work (not just in Blade) and not just by removing file I/O.

Seeing a 15% - 25% improvement (0% repeated attribute sets vs. 50% repeated attribute sets), with the following conditions:

• opcache enabled throughout
• 2000 components total
• 2/3 user attributes per component
• 1 benchmark iteration (obviously significant improvement with more iterations because of the in-memory cache, but that's not really useful)

Updates:

• I removed the in-memory cache because I couldn't find a reliable and fast way to fingerprint view data

Fun anecdote:
I went as far as checking things like whether I could replace the preg_replace in Str::snake with custom str_replace voodoo, but benchmarking showed it wouldn't save much and it was...very strange.

[github-actions]

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

[driesvints]

Tests fail here

[assertchris]

I wanted to wait until someone with clout let me know they approved of the approaches before changing the test fixtures to match the new patterns in compiled views. Kinda disappointing that this is the first bit of feedback.

[driesvints]

I'll re-open this but we normally don't review PR's with failing tests. We've had lots of issues in the past with PR's being merged with failing tests, sub sequentially causing other PR's to fail who were send after it being merged. As a precaution we simple do not accept PR's with failing tests.

[assertchris]

Not asking it to be merged with failing tests. Just some sort of 👍 for significant changes before I inflate the code to review with test changes. I will make the tests pass before taking it out of draft.

[driesvints]

@assertchris Taylor doesn't sees draft PR's.

[lonnylot]

@assertchris Your changes match a lot of the discovery I was doing.

In my tests the dispatch equated between 10-20%. So I'm curious what % of improvement in this PR can be attributed to the other changes.

[assertchris]

@lonnylot Unsure. I think there could be value in standardising a benchmark arounds all sorts of component use-cases; which could be used to benchmark improvements. My benchmark was originally slanted towards better testing the in-memory cache use-case; but I ended up removing that part of the PR.

[taylorotwell]

Solid start! 🔥

[taylorotwell]

Thanks @assertchris