Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115930
MIME-Version: 1.0
References: <CADJ56BRPi_GHE7R70k-NdgQ6ea2ogLSe6Z6Eg-YGKpeYSmvhbQ@mail.gmail.com>
 <CAJvSBVP2pCT6wDNrpVDp=1_JQtrG=H2Y2fy8L-vcvgawhWstCw@mail.gmail.com>
 <CADJ56BSHDTZ86oRqMHfsB860WXsO3ORv7JVGArJx+Q7FN4nD5g@mail.gmail.com> <0A048A30-444F-4DB0-A79C-9EA9BD07B1EC@cschneid.com>
In-Reply-To: <0A048A30-444F-4DB0-A79C-9EA9BD07B1EC@cschneid.com>
Date: Fri, 3 Sep 2021 15:07:56 +0100
Message-ID: <CADJ56BT=TDF2_fn5ci-=34cuMSeks5NzA4r5_5acVNum9PY_kw@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Adding a way to disable the stat cache
From: kevin@lyda.ie (Kevin Lyda)

On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider
<cschneid@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.

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";
}
?>

Now this is a silly toy, but imagine using is_file to see if a
graphics file exists, running an image processing program on it to
modify it, and then using a stat call to get the file length to
populate the Content-Length field - it will almost certainly be wrong.

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.

Kevin