Discussion: Remove file statcache?
| From: | Larry Garfield | Date: | Fri, 20 Dec 2024 19:26:41 +0000 |
| Subject: | Discussion: Remove file statcache? | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-126146@lists.php.net to get a copy of this message | ||
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 caching 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 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?
What additional data would you need to make the case for such removal?
--
Larry Garfield
larry@garfieldtech.com