2026年6月9日(火) 18:58 Larry Garfield <[email protected]>: > 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 >
Hi Larry > 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. Yes, that's essentially what I have in mind. However, adapting existing applications to support FrankenPHP (and other memory-resident runners) requires a considerable amount of effort. What I want to achieve with this RFC is to reach that intermediate point— to make a memory-resident cache available on an opt-in basis, even in the traditional execution model, where needed. Of course, I'm aware that there are "workarounds" using preload today. However, those only work with scalar types. Applying such optimizations to existing applications at a "truly effective level" would likely require about the same amount of effort as migrating to FrankenPHP. This RFC fixes this problem at its root. It is entirely opt-in, so users can adopt the feature only after verifying its safety and reliability. Furthermore, I believe that implementing this via Attributes offers the best cost-benefit ratio. An Attribute-based implementation is the only approach that can rival a true memory-resident one. To achieve this, I think an explanation of this complex background and consensus building are necessary. I considered postponing the Attribute-based implementation, but perhaps I should have shared this premise first. I hope this helps move the discussion forward. Best regards, Go Kudo
