Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94702
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Philip Hofstetter'" <phofstetter@sensational.ch>,
	"'PHP internals'" <internals@lists.php.net>
References: <CAGKNXQHsj54Sqpzs1S-0f8hMBVCWjz8kDSMmt1W3pJQXXmGBwQ@mail.gmail.com>
In-Reply-To: <CAGKNXQHsj54Sqpzs1S-0f8hMBVCWjz8kDSMmt1W3pJQXXmGBwQ@mail.gmail.com>
Date: Mon, 25 Jul 2016 11:47:37 +0200
Message-ID: <03dd01d1e659$96040a20$c20c1e60$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQFhF6NtoOqXFhWmNZP2vuIluze3ZKEKfpvQ
Content-Language: en-us
Subject: RE: [PHP-DEV] stat cache / still needed these days?
From: anatol.php@belski.net ("Anatol Belski")

Hi Philip,

> -----Original Message-----
> From: Philip Hofstetter [mailto:phofstetter@sensational.ch]
> Sent: Monday, July 25, 2016 9:55 AM
> To: PHP internals <internals@lists.php.net>
> Subject: [PHP-DEV] stat cache / still needed these days?
>=20
> Hi,
>=20
> I have just reported #72666 (touch() works differently on plain paths =
and file://
> paths with regards to cleaning the stat cache) and I would gladly =
provide a PR
> with a fix and unit tests. However, before I start working on this =
(well - it would
> be an easy fix), I would like to question whether the stat cache is a =
good idea
> and whether it's still (or ever was) needed these days.
>=20
> File systems right now are really good at quickly providing the
> information: On MacOS I measure only 10% loss in performance when =
doing
> nothing but calling stat() and clearstatcache() compared to just =
calling stat().
> Over NFS on Linux, it's 20%.
>=20
> Additionally, I wonder what the stat cache is actually helpful for - =
as far as I
> understand it, this only helps if you repeatedly call
> stat() (or a related function) on the same file within the same =
request which
> probably isn't very common application behaviour to begin with.
>=20
> As such, before I fix touch() to call php_clear_stat_cache(), maybe =
it's worth
> reconsidering the whole thing and removing it from PHP itself at least =
for later
> versions, though I guess there I would be in firm RFC territory which =
I'd be willing
> to write if I had RFC writing credentials.
>=20
> What do you think?
>=20
Not only single paths fill the cache, but also all the sub-paths. Say =
for /a/b/c/d, all the single sub-parts /a/b/c, /a/b, /a will be cached. =
So it's not just when some file is accessed, but when siblings with the =
joint parent are accessed. This spares a lot of recursive function calls =
for the path resolution. Especially in TS, but also in NTS variant. Even =
disregarding that, I don't really see any functional gain on removing - =
at the end the path will land in some C runtime I/O function as "last =
authority". From the experience, path's barely change within the same =
request, so the common case profits from the path caching.

Regards

Anatol