On 11/26/18 2:14 PM, Nikita Popov wrote:
> On Mon, Nov 26, 2018 at 10:15 AM Zeev Suraski <vsura...@gmail.com> wrote:
>
>> On Sun, Nov 25, 2018 at 11:43 PM Marco Pivetta <ocram...@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.
In general, this solution should work.
Thanks. Dmitry.
