Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126149
Precedence: bulk
MIME-Version: 1.0
References: <27531d9d-9bfe-4acc-b9ab-80b1017e3038@app.fastmail.com> <32bb41ba-11c0-4b20-92d9-7dce513c97a5@gmx.de>
In-Reply-To: <32bb41ba-11c0-4b20-92d9-7dce513c97a5@gmx.de>
Date: Fri, 20 Dec 2024 22:52:46 +0100
Message-ID: <CAEKnhAGQRyQBMtyUbKV6s38ncTjtc1J20RzFzLJxCz2eaBsedA@mail.gmail.com>
Subject: Re: [PHP-DEV] Discussion: Remove file statcache?
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007a646e0629baab3b"
From: bukka@php.net (Jakub Zelenka)

--0000000000007a646e0629baab3b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Dec 20, 2024 at 10:37=E2=80=AFPM Christoph M. Becker <cmbecker69@gm=
x.de>
wrote:

> On 20.12.2024 at 20:26, Larry Garfield 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
> subsequent reads on the same file can be faster.  However, it's even less
> realized that it's a single-file cache.  It literally only applies when y=
ou
> try to do two file-infomation operations on the same file in rapid
> succession, without any other file reads in between.
> >
> > There's been some discussion about making the cache disable-able, thoug=
h
> the consensus now seems to be leaning toward getting rid of it outright:
> >
> > https://github.com/php/php-src/pull/17178
> >
> > Arnaud ran some quick benchmarks and found that disabling it has a less
> than 1% impact on Symfony and WordPress.
> >
> > https://github.com/php/php-src/pull/17178#issuecomment-2554323572
> >
> > Before we go any further, is there appetite among the voting population
> to remove it?  clearstatcache() and similar functions would get stubbed o=
ut
> as no-ops, but otherwise we'd just hand the responsibility back to the OS
> where it belongs, which seems so far like it would be almost an
> unmeasurable performance difference but remove some surprise complexity.
> >
> > Would you support such a removal?
>
> I still think the stat cache should be *deprecated* first.  That gives
> users a chance to reconsider calling multiple stat related functions
> instead of doing a single stat() call.  See my previous comment[1] for
> some further details.
>
>
I don't think we should force users update their code because of negligible
perf impact. Most of the time this want play any role in perf anyway as
often for applications, that actually do something, the most time is spent
on waiting for IO. So I really don't see a reason for deprecation in this
case.

Regards

Jakub

--0000000000007a646e0629baab3b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 20, 2024 at 10:3=
7=E2=80=AFPM Christoph M. Becker &lt;<a href=3D"mailto:cmbecker69@gmx.de">c=
mbecker69@gmx.de</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">On 20.12.2024 at 20:26, Larry Garfield wrote:<br>
<br>
&gt; Background: PHP has a not-often-considered feature, the stat-cache.=C2=
=A0 That is, the runtime caches the OS stat() call for files, so that subse=
quent reads on the same file can be faster.=C2=A0 However, it&#39;s even le=
ss realized that it&#39;s a single-file cache.=C2=A0 It literally only appl=
ies when you try to do two file-infomation operations on the same file in r=
apid succession, without any other file reads in between.<br>
&gt;<br>
&gt; There&#39;s been some discussion about making the cache disable-able, =
though the consensus now seems to be leaning toward getting rid of it outri=
ght:<br>
&gt;<br>
&gt; <a href=3D"https://github.com/php/php-src/pull/17178" rel=3D"noreferre=
r" target=3D"_blank">https://github.com/php/php-src/pull/17178</a><br>
&gt;<br>
&gt; Arnaud ran some quick benchmarks and found that disabling it has a les=
s than 1% impact on Symfony and WordPress.<br>
&gt;<br>
&gt; <a href=3D"https://github.com/php/php-src/pull/17178#issuecomment-2554=
323572" rel=3D"noreferrer" target=3D"_blank">https://github.com/php/php-src=
/pull/17178#issuecomment-2554323572</a><br>
&gt;<br>
&gt; Before we go any further, is there appetite among the voting populatio=
n to remove it?=C2=A0 clearstatcache() and similar functions would get stub=
bed out as no-ops, but otherwise we&#39;d just hand the responsibility back=
 to the OS where it belongs, which seems so far like it would be almost an =
unmeasurable performance difference but remove some surprise complexity.<br=
>
&gt;<br>
&gt; Would you support such a removal?<br>
<br>
I still think the stat cache should be *deprecated* first.=C2=A0 That gives=
<br>
users a chance to reconsider calling multiple stat related functions<br>
instead of doing a single stat() call.=C2=A0 See my previous comment[1] for=
<br>
some further details.<br><br></blockquote><div><br></div><div>I don&#39;t t=
hink we should force users update their code because of negligible perf imp=
act. Most of the time this want play any role in perf anyway as often for a=
pplications, that actually do something, the most time is spent on waiting =
for IO. So I really don&#39;t see a reason for deprecation in this case.</d=
iv><div><br></div><div>Regards</div><div><br></div><div>Jakub</div></div></=
div>

--0000000000007a646e0629baab3b--