Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126152
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 20 Dec 2024 23:49:13 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <81afe16b-920d-4539-b82a-c33351e56e58@app.fastmail.com>
In-Reply-To: <32bb41ba-11c0-4b20-92d9-7dce513c97a5@gmx.de>
References: <27531d9d-9bfe-4acc-b9ab-80b1017e3038@app.fastmail.com>
 <32bb41ba-11c0-4b20-92d9-7dce513c97a5@gmx.de>
Subject: Re: [PHP-DEV] Discussion: Remove file statcache?
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Dec 20, 2024, at 3:35 PM, Christoph M. Becker 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 you 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, 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 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.
>>
>> 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.
>
> [1] <https://github.com/php/php-src/pull/5894#issuecomment-2546473892>
>
> Christoph

What exactly would deprecation look like here?  My plan was to just rip the cache out, and update clearstatcache() to be a no-op, but issue a deprecation message "Hey, this doesn't do anything anymore."  And then we can remove the function itself in like PHP 10 or something, because it doesn't hurt anything to leave it be.

I don't see there being much value to a period of "hey, this is *going* to do nothing in the future", when users couldn't do anything about it.  That just gives them a deprecation notice they cannot fix, if they're in one of the very few situations where manually clearing the cache is useful.  That doesn't seem great.

--Larry Garfield