RE: [PHP-DEV] stat cache / still needed these days?

From: Date: Mon, 25 Jul 2016 09:47:37 +0000
Subject: RE: [PHP-DEV] stat cache / still needed these days?
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-94702@lists.php.net to get a copy of this message
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? > > Hi, > > 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. > > 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%. > > 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. > > 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. > > What do you think? > 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

« previous php.internals (#94702) next »