In comparing the performance of PHP 5.2.5 file_exists calls versus C stat calls, I discovered via Windows sysinternals
ProcessMonitor that PHP seems to do a stat on each component of a file path. For example,
file_exists("e:\wamp\www\ra-v2\system\application\libraries\MY_Controller.php") appears to stat "E:\wamp", "E:\wamp\www",
etc., finally getting to the file. That compares to doing _stat64 of
"e:\wamp\www\ra-v2\system\application\libraries\MY_Controller.php" in C, which just does the stat on the file. The timings
from my tests show the C app finishing in about one-seventh the time, which is what I would expect from the PHP code doing seven
times as many stat calls.
Assuming my inference about all the stat calls is correct, is there a rationale for this? If the PHP app I am working on made just
a couple of file_exists calls, I would not bother to ask, but it uses the CodeIgniter framework which is doing >100 file_exists
calls for each page being accessed, so the affect is very noticeable.
FYI, I poked around the PHP SVN web interface for a while and found php_check_open_basedir_ex called in plain_wrapper.c, which I
suspect causes the calls, but ran out of steam before confirming the cause of the behavior.
TIA
Scott Nichol
On Thu, Oct 7, 2010 at 8:09 PM, Scott Nichol snicholnews@scottnichol.comwrote:
In comparing the performance of PHP 5.2.5 file_exists calls versus C stat
calls, I discovered via Windows sysinternals
ProcessMonitor that PHP seems to do a stat on each component of a file
path. For example,
file_exists("e:\wamp\www\ra-v2\system\application\libraries\MY_Controller.php")
appears to stat "E:\wamp", "E:\wamp\www",
etc., finally getting to the file. That compares to doing _stat64 of
"e:\wamp\www\ra-v2\system\application\libraries\MY_Controller.php"
in C, which just does the stat on the file. The timings
from my tests show the C app finishing in about one-seventh the time, which
is what I would expect from the PHP code doing seven
times as many stat calls.Assuming my inference about all the stat calls is correct, is there a
rationale for this? If the PHP app I am working on made just
a couple of file_exists calls, I would not bother to ask, but it uses the
CodeIgniter framework which is doing >100 file_exists
calls for each page being accessed, so the affect is very noticeable.FYI, I poked around the PHP SVN web interface for a while and found
php_check_open_basedir_ex called in plain_wrapper.c, which I
suspect causes the calls, but ran out of steam before confirming the cause
of the behavior.TIA
Scott Nichol
--
Hi.
This was discussed before.
see
internals@lists.php.net/msg37211.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg37211.html
Tyrael
Hi.
This was discussed before.
see
internals@lists.php.net/msg37211.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg37211.htmlTyrael
Rasmus meant (include|requrie)_once, where the same files should be caught
indeed.
As of file_exists(), why would it need realpath's logic at all?
-jv
Hi.
This was discussed before.
see
internals@lists.php.net/msg37211.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg37211.htmlTyrael
I have a question after reading through that thread -
apc.include_once_override - boolean, default is 0
Optimize include_once() and require_once() calls and avoid the
expensive system calls used.
I actually read APC was going to be doing optimizations helping the
_once calls, I guess this is what it was talking about, however I
thought it was included by default, but apparently it is not.
The manual doesn't give much more detail than "optimizes the calls" -
no warnings or anything to caution a user against it.
Someone did leave a comment saying it creates more problems than it
solves, and 5.3 implemented most of those optimizations anyway. Is
this true?
Why would someone NOT include that? I mean, the point of the opcode
cache is to optimize things. Seems like that should be on by default.
Rasmus meant (include|requrie)_once, where the same files should be caught
indeed.
As offile_exists(), why would it need realpath's logic at all?
In case open_basedir is enabled we have to do some more verifications,
as we have to resolve the true base.
johannes
Rasmus meant (include|requrie)_once, where the same files should be
caught
indeed.
As offile_exists(), why would it need realpath's logic at all?In case open_basedir is enabled we have to do some more verifications,
as we have to resolve the true base.johannes
Good point, thanks.
I think it makes sense to add a check for open_basedir value and avoid such
lookups if it is not set. In many cases this setting is empty, right?
-jv