Hi, On Thu, Jun 4, 2026 at 6:49 PM Go Kudo <[email protected]> wrote:
> Hi internals and All OPcache Static Cache RFC discussion members. > > I've made significant changes to the API to bring it to a form that most > people will find acceptable. > Currently the implementation stub is here > > https://github.com/colopl/php-src/blob/982a5f4d6bffd033f9c5a02586327c86fcef1cda/ext/opcache/opcache.stub.php > > And thank you Nicolas, Hi's more optimization and simplification bring > better performance and simplism. > This means you ever have to worry about how values are stored anymore. > Serializer is completely gone. > https://github.com/colopl/php-src/pull/4 > > I sent this email because I wanted to hear thoughts on whether > I should decide to **remove the proposed implementation of Attribute based > cache from this RFC.** > > Attribute-based caching is highly efficient and consistently delivers the > best performance. > But, it also requires the OPcache JIT to intervene. > > This requires a review by Derick, the developer of JIT, and must be > handled with caution. > I think you mean Dmitry. > Furthermore, the argument that FrankenPHP should be used if that level of > performance is required certainly makes sense. > > Originally, I drafted this RFC with the goal of “improving performance as > an extension of the existing PHP SAPI,” > so this would deviate from my initial objective. However, now that I > realize there is a demand for a “more faster integrated APCu,” > I feel that this goal might need to be deprioritized. > > This RFC also sparked a discussion about how security boundaries should be > handled. > I’ve chosen to implement it in a way that SAPI isn’t enabled unless > explicitly opted into > Do you think this meets the requirements? (I’d especially like to ask > Jakub about this.) > > Unfortunately I don't currently have much time as I need to spend all my time on stream (we have got quite tight deadline for it). The soonest I can properly spend time on this would be October. > To explain the process step by step, here is how I would like to proceed: > 1. Narrow the scope of this RFC, reach consensus and hold a vote as soon > as possible, and ensure it can be incorporated into 8.6. > 2. Create a new RFC on Attribute-based Caching to initiate a new > discussion (though this may not be ready in time for 8.6.) > > It depends on other reviewers as well but I think 8.6 might be a bit too optimistic for this considering the implementation size a potentially security impact if it doesn't work correctly. Kind regards, Jakub
