Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 208.113.200.5 as permitted sender)
In-Reply-To: <487CF99F.8090701@lerdorf.com>
References: <1216133436.6875.35.camel@amirh>  <487CEF26.7030802@lerdorf.com> <1216149220.16451.10.camel@amirh> <487CF99F.8090701@lerdorf.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <82F378CC-D174-48D2-B4BD-25C80B2BCB42@php.net>
Cc: Amir Hardon <amirh@metacafe.com>,
	PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Tue, 15 Jul 2008 14:44:25 -0500
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Subject: Re: [PHP-DEV] lstat call on each directory level
From: tswicegood@php.net (Travis Swicegood)

On Jul 15, 2008, at 2:25 PM, Rasmus Lerdorf wrote:

> Well, it is used in other places too, like in figuring out _once  
> paths.  Including the same file using different paths still needs  
> to be caught.
>
> Are you calling clearstatcache() manually anywhere?  That blows  
> away the entire realpath cache and completely destroys your  
> performance, so you will want to avoid doing that very often.

Based on what I've seen, if the realpath cache gets filled it just  
quits caching rather than pruning.  That seemed odd to me.

There was also an issue that Dmitry had fixed in 5.3 a month or so  
ago where it was caching false finds and filling the cache up more  
quickly than necessary.  I found this out through a quick extension I  
wrote to view the contents of the realpath cache.  If anyone wants to  
clean this up for inclusion in the core, I'd be more than happy to  
have it there.  You can grab a copy from my Git server:
	git://git.domain51.com/php.realpath.git

-T