Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103500
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>
In-Reply-To: <CADyq6sKGg6vnzqTsBprz8NuuPjnw_fZuC-it=K_ExoBnoXRcbw@mail.gmail.com>
Date: Mon, 26 Nov 2018 11:15:03 +0200
Message-ID: <CAJHtzny=RWQ=rNFAftwfyHjgVwX4GFVn2ZFTQ3YWd_dBLGhr_Q@mail.gmail.com>
To: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000569e83057b8dc549"
Subject: declare(cache=0) - explanation (was: Re: [PHP-DEV] [mini-RFC] Disable
 opcache per script using "declare(cache=0)")
From: vsuraski@gmail.com (Zeev Suraski)

--000000000000569e83057b8dc549
Content-Type: text/plain; charset="UTF-8"

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

--000000000000569e83057b8dc549--