Edit report at http://bugs.php.net/bug.php?id=28790&edit=1

 ID:                 28790
 Updated by:         ras...@php.net
 Reported by:        jnoll at prim dot hu
 Summary:            Add php.ini option to disable stat cache
 Status:             Assigned
 Type:               Feature/Change Request
 Package:            *General Issues
 Operating System:   *
 PHP Version:        *
 Assigned To:        pollita
 Block user comment: N
 Private report:     N

 New Comment:

You guys realize that the stat cache is per-request, right? You only
need to 

clear the stat cache before a file_exists() call if you A. did a stat
for it, and 

B. either created or deleted it on that request. In which case you
shouldn't need 

to stat it again since the success status of the create/delete will tell
you 

whether the file is there or not. Perhaps for long-running daemons or
something 

this becomes more of an issue, but for a typical web request the stat
cache 

typically saves you dozens of system calls.


Previous Comments:
------------------------------------------------------------------------
[2011-03-31 06:47:29] giorgio dot liscio at email dot it

when this will be fixed?

when lot of users work on same files is needed to clear the cache on
every call to stat functions: this is totally annoying



in plus clearing the cache every time is slower against not cache at
all



please fix :)



thank you

------------------------------------------------------------------------
[2007-05-23 22:57:09] bcurry at freeshell dot org

I'd like to second the motion for an .INI-option enabling the stat
cache, defaulting to 'true.' In my case, I would certainly set this
option to 'false.'



In my humble opinion, the stat cache should either invalidate itself on
every file access and modification - or not cache entries, at all. I
depend on "file_exists" returning 'true' if a file exists, and 'false'
if not. Enabling the stat cache makes this (and similar) built-in
functions behave non-deterministically, and therefore un-reliably. The
"speed" gain of caching stat results is surely obviated by the fact
that, to obtain reliable stat results, one must call "clearstatcache"
before every call to the "file_exists" (and similar) built-in functions.

------------------------------------------------------------------------
[2006-12-31 09:17:43] james at bytehosting dot com

When writing a daemon process that accesses files very often it seems
litterally stupid to cache stat on these files.



With Basic Code such as the below, the statcache adds unneccessary
overhead and actully SLOWS down the code caching & purging the cache on
EACH and EVERY revolution of code.



There MUST be an option to disable it, other than rm -rf'ing the stuff
from the src/.



Regardless if you believe its "quicker" or not is moot, for each and
every case that you give where it is quicker, I can garuntee to give you
a seperate case proving where it slows the code down.



If your not willing to add a config option, how about a runtime option? 
(after all, who needs ob_implicit_flush()? its just another 'useless'
function..., same idioligy applies here). And there are PLUNTY of cases
where code such as this is required (obviously, not the exact code, its
pseudo code)



while (TRUE) {

  clearstatcache();

  if (file_exists("file.tmp")) {

       process_stuff;

  }

}

------------------------------------------------------------------------
[2004-06-16 17:30:45] poll...@php.net

I'll cut ya in on a secret: The statcache is only one entry long.

------------------------------------------------------------------------
[2004-06-16 17:28:42] phpbugs at spam dot raszi dot hu

It would be better if the file modification functions invalidate not the
whole statcache, only the entry of the modified file.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    http://bugs.php.net/bug.php?id=28790


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=28790&edit=1

Reply via email to