[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-internals
Subject:    Re: [PHP-DEV] declare(cache=0) - explanation (was: Re: [PHP-DEV] [mini-RFC] Disable opcache per scri
From:       Nikita Popov <nikita.ppv () gmail ! com>
Date:       2018-11-26 11:14:40
Message-ID: CAF+90c8eCE96=ZAfQ4icvc5__1DQi6Bz2EoHR3=WfFp0qVphEg () mail ! gmail ! com
[Download RAW message or body]


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


[prev in list] [next in list] [prev in thread] [next in thread]