On Wed, Jun 3, 2026, at 5:53 PM, Nicolas Grekas wrote: > 4. Attributes. You kept them as "ergonomic surface, no new storage > model", but that does not answer the cost I raised: the JIT paths, the > VM hooks, and the CacheStrategy::Tracking machinery exist only for the > attribute case, and the reserved-key leak in #1 is their concrete > footprint on the explicit API. None of that is needed by the explicit > cache. That is exactly why I would split them into a follow-up: the > explicit cache can land and be reviewed on its own, while the attribute > semantics (cross-request shared mutable state, mutation tracking) get > the separate scrutiny they deserve. Bundled, they couple the review of > a simple primitive to the riskiest part of the patch. > > 5. Pinned/non-volatile I remain unconvinced. You proved that > "materialize once per worker, then a near-zero static read per request" > is something per-request hydrate cannot match. That is real but it is > narrow. If one cares about perf that much, then moving to a > worker-based runtime model (aka FrankenPHP workers) provides way more > evident perf improvement and doesn't need pinning at all since there, > static properties are live for a worker-long duration.
FrankenPHP has been sitting in the back of my head for this whole discussion. :-) The problem is that we are looking at three different levels of potential caching. This RFC - relatively easy to use, may or may not need to re-materialize objects, fairly fast. Compile to disk - hard to implement well, need to re-materialize objects, even faster. Persistent process (Franken, Swoole, etc.) - Super simple to use, fastest option available. I like the idea of this RFC, but part of me wonders if we should just say "use Franken, really." But then the fallback if you aren't running Fraken is the hardest to implement option. So why would I do that, when I have an easier to use option? So, potentially, would that mean the options are "use this RFC or Franken, and the compiled option just kinda fades away?" (At least for data; for generated classes we'd still need it.) I'm not sure. Just me thinking aloud... --Larry Garfield
