Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126162
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 21 Dec 2024 22:09:19 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <e8736456-218d-4a55-a595-e1346e1c6d20@app.fastmail.com>
In-Reply-To: 
 <CAEKnhAFU32EXh483QzR0LLUt+Jou4ejKjOXqBQ_G43wR7LW5cA@mail.gmail.com>
References: <27531d9d-9bfe-4acc-b9ab-80b1017e3038@app.fastmail.com>
 <CAEKnhAFU32EXh483QzR0LLUt+Jou4ejKjOXqBQ_G43wR7LW5cA@mail.gmail.com>
Subject: Re: [PHP-DEV] Discussion: Remove file statcache?
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Dec 21, 2024, at 10:43 AM, Jakub Zelenka wrote:
> On Fri, Dec 20, 2024 at 8:29=E2=80=AFPM Larry Garfield <larry@garfield=
tech.com> wrote:
>> Background: PHP has a not-often-considered feature, the stat-cache.  =
That is, the runtime caches the OS stat() call for files, so that subseq=
uent reads on the same file can be faster.  However, it's even less real=
ized that it's a single-file cache.  It literally only applies when you =
try to do two file-infomation operations on the same file in rapid succe=
ssion, without any other file reads in between.

> I would prefer to disable it by default but keep some option (INI) to=20
> re-enable it. I think that for most users the perf impact will be=20
> negligible. However, it is quite likely that there are some user=20
> workflows and platforms where benefiting from the stat cache can be=20
> still significant in terms of performance. So those users should have=20
> the option to re-enable it if they see some significant regression=20
> rather then force them to update their code to make it faster or=20
> implement their own cache which would just make their migration to the=20
> next version much harder / potentially impossible. There is not such a=20
> huge maintenance that we would really need to get rid of it completely=
.=20
> I would really prefer having such option and tell to users to re-enabl=
e=20
> it rather than not be able to deal with potentially reported future=20
> perf regressions.=20
>
> I think the main issue with the cache is that is just not convenient=20
> for use cases where it doesn't get flushed during some different acces=
s=20
> methods that don't trigger flush. We could probably improve the stream=20
> situation a bit but it still leaves external (e.g. shell) access=20
> problem in place which we just cannot fix. On the other hand it is=20
> possible to use it in a way that users can profit from it but they=20
> really need to know how it works. That's way it should be an optional=20
> feature IMO. We should also improve documentation in that regards.
>
> In terms of voting, if there was no option to re-enable it, I would=20
> probably vote against this proposal as I'm a bit worried about those=20
> possible regression reports.

I really don't like the idea of another ini toggle.  That actually creat=
es more work, as people writing code that works with the file system now=
 have one more invisible context they have to think about.  Which means =
they probably won't, until it bites them.  (They'll either never bother =
clearing the cache, so their code may malfunction on the rare system whe=
re it's enabled, or always clear it, which 99.9% of the time will actual=
ly be slower as we have to invoke the function for it to do nothing.  Bo=
th are bad.)

I suppose a possible alternative would be to modify all file system muta=
tion functions (file_put_contents(), touch(), etc.) to flush the cache, =
which for whatever reason doesn't happen now.  That would be above my sk=
ill level, though, so someone else would need to do it.  Also, I don't k=
now if there's a good reason those functions don't clear the cache curre=
ntly or if it was just an oversight.

--Larry Garfield