Req #28790 [Com]: Add php.ini option to disable stat cache

From: Date: Thu, 31 Mar 2011 04:47:29 +0000
Subject: Req #28790 [Com]: Add php.ini option to disable stat cache
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-159866@lists.php.net to get a copy of this message
Edit report at http://bugs.php.net/bug.php?id=28790&edit=1 ID: 28790 Comment by: giorgio dot liscio at email dot it 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: 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 Previous Comments: ------------------------------------------------------------------------ [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] pollita@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. ------------------------------------------------------------------------ [2004-06-16 16:29:51] pollita@php.net Ilia was perhaps a bit short winded in his response... This was actually discussed within the context of a feature change as well and was turned down on the basis that it would create unnecessary slowdowns without significant gain. You should be aware when you're making multiple stat family calls to the same file and call clearstatcache() accordingly. If you're uncertain, then just call it anyway. However, that said it may be prudent to introduce an .ini option to disable the cache altogether now that stat calls work on arbitrary wrappers. Let's leave this option open for PHP 5.1 for now. ------------------------------------------------------------------------ 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

« previous php.bugs (#159866) next »