Am 03.09.2021 um 16:07 schrieb Kevin Lyda <ke...@lyda.ie>:
> On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider
> <cschn...@cschneid.com> wrote:
>> If I remember correctly it was about reducing the number of system calls. Is
>> this no issue any more?
>> Has a quick benchmark been done to see the positive / negative impact of the
>> stat cache for a typical application?
>
> In the lifespan of php it really wasn't an issue unless someone was
> doing something that wasn't wise - I can't think of a single reason to
> stat a file in a tight loop.
How can you say "it never was a problem" if we never had to live without stat
cache?
Can you back up that claim with numbers? There are some of us who run
high-volume websites where system load increase could be a problem.
> However more importantly the current behaviour returns bad data for
> perfectly correct programs. So for example on a unix box...
>
> <?php
> passthru('touch foo');
> if (is_file('foo')) {
> echo "Correct\n";
> }
> passthru('rm foo');
> if (is_file('foo')) {
> echo "Incorrect\n";
> }
> ?>
I disagree that this (with current PHP) is a correct program. The documentation
at
https://www.php.net/manual/en/function.is-file.php#refsect1-function.is-file-notes
<https://www.php.net/manual/en/function.is-file.php>
clearly states that is_file() is cached and clearstatcache() should be used.
Yes, the stat cache is a foot gun, but it was put in for a reason back in the
day.
> Personally I value correctness first and then performance is a
> priority further down that list of attributes (security and
> readability would also be higher priorities). However as the current
> behaviour has existed for several decades, this change makes sure the
> incorrect historical behaviour is the default.
There are two problems here:
a) Removing the stat cache altogether (which is not your proposal, I know, but
it was mentioned in the thread) could lead to a performance regression. I was
asking for data backing up the claim that this regression either does not exist
or is small enough to not be a problem. Just saying "it never was a problem" or
"modern Linux should handle this" does not give me that certainty.
b) Making it an .ini-Option seems to be a BC preserving measure but, in fact,
it creates an even bigger issue: Your code snippet is correct or buggy
depending on an ini-settings. Something we want to avoid as much as possible,
see magic_quotes :-)
- Chris
