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). 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
