it appears that zend_stream_open .. and hence fopen is called on every require_once/include_once
would it make sense to add something as simple as
if (opline->op2.....lval == ZEND_REQUIRE_ONCE) {
locations = get_potential_locations(file,PG('include_path'));
foreach (locations as location)
if (zend_hash_find(&EG(included_files), location)) {
// i've already got it !
NEXT_OPCODE();
}
}
}reduce the stat calls substancially?? - especially where we have cases that alot of the pear classes already have "require_once 'PEAR.php'" .. even though it may have already been loaded by another package...
Or did I miss some other optimization that is already there for that..?
.. Yeah, I see from APC in CVS, it only wraps the compile_file() call, which has recieves a file pointer, so the stating/realpath damage etc. has already been done) - so unless it does something similar to the above check, and overrides the include handler, it wont help much either, I guess..
Regards Alan
Rasmus Lerdorf wrote:
It can be significant. There are a couple of issues:
1. The included_files list gets updated each time you include a file. In order to make sure that the same file included by different paths or symlinks don't conflict we do a realpath() on the file to be included. That means stats on every component up to and including the file itself. I can't speak for all the opcode caches, but at least APC doesn't do anything to alleviate this.
2. APC uses the file's device and inode as the lookup key into shared memory to find the opcodes for the file, so a stat has to be done on each and every file that is cached. There is currently no such thing as a request-spanning stat cache.
So yes, jumping from 20 to 30 include files could very well bring a rather significant performance hit.
Anybody looking for real performance out of PHP pretty much has to address the first issue. It is easy enough to do, simply get rid of the realpath lookup in that situation and just live with the fact that if someone includes the same file via different paths it won't catch it. I can see that it is convenient to have PHP figure this out for you, but the price of that convenience is not worth it in my opinion.
-Rasmus
On Sat, 24 Apr 2004, Alan Knowles wrote:
PEAR is considering stipulating 1 class per file, for the packages. - one of the concerns raised is performance. While this is true for a non-cache compiled situation (where performance is less of an issue) - would anyone care to comment on the implications when using the Zend Optimizer or APC, on how significant the impact of this would be.
- looking at typical application where the number of files included in the code with may jump from 20->30 included files..
From my understanding, if you where looking for performance, you would probably have a cache expiry which would mean very few stat (if any) calls based on these addition includes.. - hence negating the issue..
Thanks Alan
-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
