Blade class component loop performance profile on 13.x with OPcache enabled

[mehmetcansahin]

Context

I have been looking into Blade class component performance in loops on the current 13.x branch, especially in the context of prior work and discussions around:

• Rendering components in loop severely impacts performance #43811
• [9.x] Makes blade components blazing fast ⛽️ #44487
• [11.x] Add in-memory cache support to Blade #51141
• [11.x] Supercharge Blade #51143
• [11.x] Add component view instance caching #51152
• [11.x] Blade Component Loop Speed Improvement #51158
• [12.x] Add @includeIsolated directive for isolated Blade includes #58311

The goal was not to open another speculative optimization PR, but to measure where the cost currently sits with OPcache enabled.

Environment

• Branch: 13.x
• PHP: 8.5.6
• OPcache CLI: enabled
• Benchmark shape:
  • class components rendered in loops
  • counts: 100, 1000, 5000
  • scenarios: static component, attributes, slots, public methods, anonymous components
  • separate lifecycle micro-breakdown

Summary

The main finding is that Component::data() / public method reflection is measurable in isolated micro benchmarks, but it does not dominate full Blade render time.

In full render benchmarks, the dominant cost appears to be compiled component view evaluation through CompilerEngine::get() / View::render(), not:

• Factory::make()
• cached view lookup
• public method reflection
• ComponentAttributeBag alone
• slot rendering alone

Full Render Results

OPcache enabled, median:

Scenario	5000 renders	Per item
Plain Blade loop	0.715 ms	0.143 us
Static class component	111.892 ms	22.378 us
Attributes + slot class component	120.699 ms	24.140 us
Methods exposed but unused	123.930 ms	24.786 us
Methods used	129.772 ms	25.954 us
Anonymous attributes + slot	115.750 ms	23.150 us

Lifecycle Breakdown

OPcache enabled, median:

Operation	Cost
Component::resolve()	0.339 us/op
Component::resolveView() cached inline	0.226 us/op
Component::data() static component	0.695 us/op
Component::data() with public methods	1.223 us/op
withAttributes() after data	0.926 us/op
Factory::make() only	0.566 us/op
CompilerEngine::get() static view	15.954 us/op
CompilerEngine::get() attributes + slot view	17.927 us/op
View::render() static view	16.700 us/op
Factory::make()->render() static view	17.554 us/op

Notes

I initially looked at caching ReflectionMethod metadata inside Component::data().

That improved isolated micro benchmarks, but did not seem worthwhile as a core PR because full render improvements were inconsistent and usually below 5% with OPcache enabled.

That seems consistent with prior feedback on #51141 and #51152: once OPcache is enabled, file I/O or view instance caching style optimizations do not necessarily move the needle enough, and some approaches can introduce side effects.

Question

Given these results, is the intended direction:

1. treat this as an acceptable tradeoff of Blade components,
2. prefer lighter alternatives such as @includeIsolated for hot loops / simple partials,
3. explore a lower-overhead component render path,
4. or standardize a benchmark fixture for Blade component performance before considering further PRs?

I am happy to clean up and share the benchmark script if that would be useful.