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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
