Well, judging from my own experience, most people do either a full path include, or a relative path include from the current directory such as a/b/c.php and similar. So for these cases we can bypass tokenizing the patch at an fairly light cost of 2 memchr() calls.
The realpath may alleviate the problem to a certain extent but if you do not have to do certain code it would still be faster. While on the realpath cache, would it be limited to persistent environments such as Apache only? In addition, such a cache may grow to be rather large on a server where fileio operations are very common, for example a server using files session mechanism or a server where PHP generates file caches of 'dynamic' data. The realpath cache would also need some logic to handle situation when the cached path is invalidated, meaning that a stat() + inode check or something more elaborate would need to occur. From performance perspective that is something I'd like to avoid.
The bottom line is such that at the moment based on latest php4 sources doing a file operation is ~25%-35% slower then it could/should be (memchr patch + avoid realpath() unless safe_mode/open_basedir are in use patch).
I don't think realpath() should be avoided because of symbolic links (even if you do strip it from ./ and ../).
We are talking about a relatively small cache IMO (you can limit it to the X most accessed pages if you want) and it would mainly server the expand_filepath() functionality in PHP. It doesn't need to server sessions and all the rest you mentioned.
I don't think we need a stat() or inode cache for realpath() caches. It isn't the same as a file cache. You can timeout entries if they aren't used for like 5 minutes or so.
It's really quite simple. Make a hash that holds a structure which has the realpath() and time of entry in it. If it's still relevant use it. If you want to limit the hash to X entries (no need IMO) the easy way is to just limit it to something which makes sense like first 500 pages (which will most probably be the most accessed ones anyway).
Need to go now.
Andi Andi
Ilia
On June 11, 2003 12:15 am, Andi Gutmans wrote: > At 09:51 PM 6/10/2003 -0400, Ilia A. wrote: > >There are a several things that could be done to speed file opening > > process up. Attached is a fairly simple patch that in most cases > > optimizes potentially expensive code that looks for ../ and ./ in the > > path. > > This sounds like a weird patch to me. How many people have ./ and ../ in > their path? Or are there a lot due to "." being in include_path? If so, it > might not be that weird after all :) > > Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
