Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126147
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Subject: Re: [PHP-DEV] Discussion: Remove file statcache?
In-Reply-To: <27531d9d-9bfe-4acc-b9ab-80b1017e3038@app.fastmail.com>
Date: Fri, 20 Dec 2024 16:10:39 -0400
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C368F366-9EEF-4D3B-9A9C-6D2C915E7761@cmpct.info>
References: <27531d9d-9bfe-4acc-b9ab-80b1017e3038@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
From: calvin@cmpct.info (Calvin Buckley)

On Dec 20, 2024, at 3:26=E2=80=AFPM, Larry Garfield =
<larry@garfieldtech.com> wrote:
>=20
> 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.
>=20
> For more info: =
https://tideways.com/profiler/blog/the-php-stat-cache-explained
>=20
> 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 =
caching bugs in applications.
>=20
> 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.
>=20
> 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:
>=20
> https://github.com/php/php-src/pull/17178
>=20
> Arnaud ran some quick benchmarks and found that disabling it has a =
less than 1% impact on Symfony and WordPress.
>=20
> https://github.com/php/php-src/pull/17178#issuecomment-2554323572
>=20
> Before we go any further, is there appetite among the voting =
population to 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.
>=20
> Would you support such a removal?
> What additional data would you need to make the case for such removal?
>=20
> --=20
>  Larry Garfield
>  larry@garfieldtech.com

At least on the platform I'm supporting (IBM i), filesystem calls can be
quite slow. I know it's similar on Windows too. That said, I think
getting rid of the stat cache is probably the right call. It's better to
do this at the OS or application levels, where they know more about the
workload (either because they have a system view, or the app knows what
it needs to keep). I haven't measured this yet though.=