Stanislav Malyshev wrote:
> Hi!
>
>> A good point. Fortunately, most streams do store the filename in the
>> stream struct, so this would still probably be possible in the majority
>> of cases. If not available, the original requested filename is used
>> (the one from the fopen call), so opcode caches probably could just use
>> that.
>
> The problem is, by then the stream will already be opened, i.e. extra
> filesystem call is done.
Hi,
Yes, but let's not forget we're talking about making this:
<?php
if ($fp = @fopen($file, 'r', true)) {
fclose($fp);
include $file;
}
// 2 stats, fopen + include
?>
into this:
<?php
if ($fp = @fopen($file, 'r', true)) {
include($fp);
fclose($fp);
}
// 1 stat, fopen
?>
Of course 1 stat is worse than no stats. Perhaps better would be to introduce
a function:
if (can_include($file)) {
include $file;
}
opcode caches could easily snag this, as we could provide a simple hook the way
we do with stream_resolve_path(). That would actually make a 0-stat smart
autoloader a possibility. Just in case it isn't obvious, can_include() would
be the equivalent to an include_path search followed by is_readable(), which is
essentially what the fopen() hack does now. can_include() would also remove
the unnecessary opening of the file that fopen() performs.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
