Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103505
MIME-Version: 1.0
References: <BY1PR02MB12606B0B2C6878B6F73D151BBFD40@BY1PR02MB1260.namprd02.prod.outlook.com>
 <CAF+90c_6Vwz+GguSfCGQw5ncmcSBGXnXP4yo1KymLDMEaL19Hw@mail.gmail.com>
 <BY1PR02MB1260D6A74881B45987CC462EBFD40@BY1PR02MB1260.namprd02.prod.outlook.com>
 <F1BA9936-6BCD-47C8-90B8-B011B472A610@gmail.com> <CAJHtznxOm=YR8FcUDx_M-Fv9WgP-PtT+vg4G5_sMom2EJK5iEA@mail.gmail.com>
 <1cb7fecd-22ba-0ded-5bd6-e70208053012@gmail.com> <7f65012b-e26a-fb58-718b-b35569e53d03@gmail.com>
 <CADyq6sLWz3rZaPCu-AZtCoKCQGC4SiJra66w+6cdeFvk58FJ_A@mail.gmail.com>
 <CAJHtznxQOnZZEhnXP-KY+iMSQ-0BBwWFhHaofU2+R+=ZxXx0VQ@mail.gmail.com>
 <CADyq6sKGg6vnzqTsBprz8NuuPjnw_fZuC-it=K_ExoBnoXRcbw@mail.gmail.com> <CAJHtzny=RWQ=rNFAftwfyHjgVwX4GFVn2ZFTQ3YWd_dBLGhr_Q@mail.gmail.com>
In-Reply-To: <CAJHtzny=RWQ=rNFAftwfyHjgVwX4GFVn2ZFTQ3YWd_dBLGhr_Q@mail.gmail.com>
Date: Mon, 26 Nov 2018 12:14:40 +0100
Message-ID: <CAF+90c8eCE96=ZAfQ4icvc5__1DQi6Bz2EoHR3=WfFp0qVphEg@mail.gmail.com>
To: Zeev Suraski <vsuraski@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000088a164057b8f7143"
Subject: Re: [PHP-DEV] declare(cache=0) - explanation (was: Re: [PHP-DEV]
 [mini-RFC] Disable opcache per script using "declare(cache=0)")
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000088a164057b8f7143
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 26, 2018 at 10:15 AM Zeev Suraski <vsuraski@gmail.com> wrote:

> On Sun, Nov 25, 2018 at 11:43 PM Marco Pivetta <ocramius@gmail.com> wrote:
>
> > Is that space rrrrrrreeeeeally a problem?
> >
> > Take the example ZF loader from the RFC: that barely makes any difference
> > at all.
> >
> > A stronger reasoning for another language construct (that changes engine
> > behaviour) is kinfa required.
> >
>
> The emails I've written on this thread already suggested that I tend to
> agree.  I just spoke with Dmitry to better understand why he cared about so
> little space, and turns out he didn't either - the rationale is different
> and is pretty straightforward.
>
> The goal of declare(cache=0) would be to avoid persisting utility
> functions/classes that have to do with a particular preload.php
> implementation - so that they don't become a part of the app's memory
> context and 'pollute' its scope.
>
> For example, you may implement a preload_file() function in preload.php, or
> perhaps even a class Preload{} with some utility functions that will be
> responsible for include()ing all the various files you want to preload into
> your server. Currently, function preload_file() / class Preload would
> become permanent parts of the app's scope - and pollute it to some degree.
> They're sort of meta-code that has no business sticking around in the app's
> memory space once the preloading stage is over.  With declare(cache=0) -
> these will execute just as before, but won't be persisted into the
> permanent scope (or into the OPcache at all, for that matter).
>
> There's no way to 'automatically' apply this 'do-not-cache', as in
> different implementations - the preload.php file might actually include
> classes/functions folks would actually want to persist, and in other cases
> files include()ed by preload.php may in fact include functions/classes
> people do not want to persist.  This has to be a manually-applied feature.
>
> As I mentioned in another reply on this thread, it's also a nice
> runtime/configurationless alternative for the blacklist feature, in case
> you want to prevent certain files from being cached for whatever reason
> (that use case is unrelated to the preload capability).
>
> I'm personally fine with this being admitted w/o a full fledged RFC if
> there are no objections.
>
> Zeev
>

It would make more sense to me to not cache anything from the preload
script or anything it includes, and only make things for which
opcache_compile_file() is called part of the preload. As I understand it,
right now both included and compiled files will be preloaded.

I think that would be a better solution than a declare annotation, because
it would allow you to use arbitrary code in your preload script. You could
make use of normal library code -- something that would be much harder if
you had to hot-patch the library to include no-cache directives first.

Nikita

--00000000000088a164057b8f7143--