# stat functions do each path component? - Thread: https://externals.io/message/49885 - Original archive: https://news-web.php.net/php.internals/49885 - Started by Scott Nichol on 2010-10-07T18:09:11+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49885 — Scott Nichol — 2010-10-07T18:09:11+00:00 URL: https://externals.io/message/49885#49885 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 --- ## #49886 — Ferenc Kovacs — 2010-10-07T18:21:23+00:00 URL: https://externals.io/message/49885#49886 · In reply to: #49885 On Thu, Oct 7, 2010 at 8:09 PM, Scott Nichol wrote: > 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 http://www.mail-archive.com/internals@lists.php.net/msg37211.html Tyrael --- ## #49888 — jvlad — 2010-10-08T09:47:58+00:00 URL: https://externals.io/message/49885#49888 · In reply to: #49886 > Hi. > > This was discussed before. > see > http://www.mail-archive.com/internals@lists.php.net/msg37211.html > > Tyrael > 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 --- ## #49889 — Michael Shadle — 2010-10-08T10:03:54+00:00 URL: https://externals.io/message/49885#49889 · In reply to: #49888 > > […] 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. --- ## #49890 — johannes@schlueters.de — 2010-10-08T10:07:12+00:00 URL: https://externals.io/message/49885#49890 · In reply to: #49888 > 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? In case open_basedir is enabled we have to do some more verifications, as we have to resolve the true base. johannes --- ## #49891 — jvlad — 2010-10-08T11:19:02+00:00 URL: https://externals.io/message/49885#49891 · In reply to: #49890 > > […] > > 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