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.

Thanks for the clarification, that makes a lot more sense than the
performance impact.

As I mentioned before, though, the behaviour of the following case is not
obvious to me:

preload.php

require 'foo.php';
require 'bar.php';

foo.php

declare(cache=0);
class Foo {}

bar.php

class Bar extends Foo {}

At the time it is first parsed, Bar is a complete class, and is being
defined during preload, so ought to be defined permanently; but it depends
on Foo, which will not be cached. Will this be an error, or will class Bar
simply not be defined on future requests?

Regards,

Rowan Collins
[IMSoP]

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