Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126150
Precedence: bulk
MIME-Version: 1.0
References: <27531d9d-9bfe-4acc-b9ab-80b1017e3038@app.fastmail.com>
In-Reply-To: <27531d9d-9bfe-4acc-b9ab-80b1017e3038@app.fastmail.com>
Date: Fri, 20 Dec 2024 23:34:42 +0100
Message-ID: <CANS-=pd4z_Ksd7p4iGgsRbMM_OU=CVdTD+S-n_syNSDW=nVTpg@mail.gmail.com>
Subject: Re: [PHP-DEV] Discussion: Remove file statcache?
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006708110629bb42d1"
From: kjarli@gmail.com (Lynn)

--0000000000006708110629bb42d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 20, 2024 at 8:29=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
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 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 you try to
> do two file-infomation operations on the same file in rapid succession,
> without any other file reads in between.
>
> For more info:
> https://tideways.com/profiler/blog/the-php-stat-cache-explained
>
> Because it's so rarely relevant, in the cases it is relevant, it can be
> quite a surprise, and a surprise causing weird and hard to explain cachin=
g
> bugs in applications.
>
> The cache also dates from 20 years ago, when Rasmus added it (and the
> realpath cache) in Yahoo's forked PHP 4, and then it got integrated into
> PHP 5.  However, hard drives are vastly faster than they were then, and
> operating systems are vastly more efficient than they were then.
>
> There's been some discussion about making the cache disable-able, though
> 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 t=
o
> remove it?  clearstatcache() and similar functions would get stubbed out =
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?
> What additional data would you need to make the case for such removal?
>
> --
>   Larry Garfield
>   larry@garfieldtech.com


This gets a +1 from me. I've had bugs that I suspected were caused by this
cache, but I was never able to confirm it until putting clearstatcache() in
production. That's not a workflow I'd like to follow, and it has wasted
enough of my time.

--0000000000006708110629bb42d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 20,=
 2024 at 8:29=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfiel=
dtech.com">larry@garfieldtech.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Background: PHP has a not-often-considered=
 feature, the stat-cache.=C2=A0 That is, the runtime caches the OS stat() c=
all for files, so that subsequent reads on the same file can be faster.=C2=
=A0 However, it&#39;s even less realized that it&#39;s a single-file cache.=
=C2=A0 It literally only applies when you try to do two file-infomation ope=
rations on the same file in rapid succession, without any other file reads =
in between.<br>
<br>
For more info: <a href=3D"https://tideways.com/profiler/blog/the-php-stat-c=
ache-explained" rel=3D"noreferrer" target=3D"_blank">https://tideways.com/p=
rofiler/blog/the-php-stat-cache-explained</a><br>
<br>
Because it&#39;s so rarely relevant, in the cases it is relevant, it can be=
 quite a surprise, and a surprise causing weird and hard to explain caching=
 bugs in applications.<br>
<br>
The cache also dates from 20 years ago, when Rasmus added it (and the realp=
ath cache) in Yahoo&#39;s forked PHP 4, and then it got integrated into PHP=
 5.=C2=A0 However, hard drives are vastly faster than they were then, and o=
perating systems are vastly more efficient than they were then.<br>
<br>
There&#39;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:<=
br>
<br>
<a href=3D"https://github.com/php/php-src/pull/17178" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/php/php-src/pull/17178</a><br>
<br>
Arnaud ran some quick benchmarks and found that disabling it has a less tha=
n 1% impact on Symfony and WordPress.<br>
<br>
<a href=3D"https://github.com/php/php-src/pull/17178#issuecomment-255432357=
2" rel=3D"noreferrer" target=3D"_blank">https://github.com/php/php-src/pull=
/17178#issuecomment-2554323572</a><br>
<br>
Before we go any further, is there appetite among the voting population to =
remove it?=C2=A0 clearstatcache() and similar functions would get stubbed o=
ut as no-ops, but otherwise we&#39;d just hand the responsibility back to t=
he OS where it belongs, which seems so far like it would be almost an unmea=
surable performance difference but remove some surprise complexity.<br>
<br>
Would you support such a removal?<br>
What additional data would you need to make the case for such removal?<br>
<br>
-- <br>
=C2=A0 Larry Garfield<br>
=C2=A0 <a href=3D"mailto:larry@garfieldtech.com" target=3D"_blank">larry@ga=
rfieldtech.com</a></blockquote><div><br></div><div>This gets a=C2=A0+1 from=
 me. I&#39;ve had bugs that I suspected were caused by this cache, but I wa=
s never able to confirm it until putting clearstatcache() in production. Th=
at&#39;s not a workflow I&#39;d like to follow, and it has wasted enough of=
 my time.</div></div></div>

--0000000000006708110629bb42d1--