3 ms·
My initial thought was "surely it's just a quick hash lookup", but then require_once is probably using the canonical path for that lookup, which involves callin
by forgotusername 15y ago
My initial thought was "surely it's just a quick hash lookup", but then require_once is probably using the canonical path for that lookup, which involves calling realpath() or abspath(), at that point all bets are probably off, especially in a shared hosting environments involving things like NFS.
Edit: I looked at the implementation. require_once/include_once unconditionally opens the file, whether it has been loaded already or not. Attempting to follow that path through about 10 levels of indirection (seriously), at some point the PHP implementation passes its notion of the path back to Zend, which suggests possible abspath() etc. Also somewhere in PHP's streams.c I see it unconditionally seek()ing the new file too.
If nothing else, then the layers of crap I just trawled through might cause some slowness, if not some heavy library call like abspath().
I just remembered why I stopped using PHP. :)
- spudlyo 15y agoUgh, you're bringing up bad memories for me. I was once bit badly by the require_once/realpath() problem. require_once("/foo/bar/baz/random/crap/foo.php"); The above requires 5 lstat(2) system calls thanks to realpath() and a typical WordPress-MU page load for us was calling lstat over 5k times. Over NFS that's 5k round trips to the server for every page load. Thankfully there is a knob you can tune in PHP 5.1.x (realpath_cache_size) that caches all those lstats, but as usual, the default is (16K) is too small to be of any use.