Hi, On Fri, Dec 20, 2024 at 10:37 PM Christoph M. Becker <cmbecke...@gmx.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 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. > > 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
