This is the very *simple* point we have been trying to emphasize on for several months. If the file is missing, not in the path, not readable, la, blah, blah... let the application bomb - much more *gracefully*! is_readable is not going to validate everything the framework needs to validate and we cannot go about validating every aspect of the logic - that would be a messy bloat. eek!
If someone's include_path is broken then they should fix it.
On 11/30/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
We already have a realpath() cache in the PHP core, and are planning to also see if we can get a stat() cache into PHP too (probably PHP 5.2 series). Btw, I'm personally not a big fan of that is_readable() check. I don't see why not just do include_once(). If someone's include_path is broken then they should fix it. Andi > -----Original Message----- > From: Richard Thomas [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 30, 2006 7:07 AM > To: Zend Framework General > Subject: Re: [fw-general] Opcode cache [was: Shared server load times] > > Question, ok Opcode cache compiles and buffers files, but > does it "skip" > checks.. For example Zend::loadClass does a ton of "checks" > to make sure the file exists and can be loaded. > > Since these checks are seperate from the include_once itself, > even though the code and the file being included is opcached, > you would still have the overhead of checking that the file > exists won't you? > > Basically even though the file is opcached, the system is > going to do a isReadable on it to make sure it exists. > > So all these extra checks really eat away at the advantage a > opcache gives? > > Example ( consolidated from Zend.php just to provide and example ) > > <?php > > $path = get_include_path(); > $dirs = explode(PATH_SEPARATOR, $path); > > foreach ($dirs as $dir) { > // No need to check against current dir -- > already checked > if ('.' == $dir) { > continue; > } > > if (is_readable($dir . DIRECTORY_SEPARATOR . > $filename)) { > include_once($dir . DIRECTORY_SEPARATOR . $filename); > return true; > } > } > > ?> > > With opcache, I know physical loading and compiling for the > include_once gets cached, but does the loop and is_readable > happen over and over? > > > > Richard Thomas - Code Monkey > Cyberlot Technologies Group Inc. > 507.398.4124 - Voice > > > Arnaud Limbourg wrote: > > On the performance issues. Yes requiring files has an > impact but in a > > typical application a profiling will probably show that > most of the time > > is spent getting data from the database and on the logic > you implement. > > > > Arnaud. > > > > Shahar Evron wrote: > >> Hi, > >> > >> Thomas Weidner wrote: > >>>> One important thing to note is __autoload does not play well with > >>>> opcode cache last I checked. > >>> Has anyone knowledge is opcode cache works with the optimizer when > >>> using encryption and obfuscation ?? > >> > >> Are you asking about Zend Optimizer? Yes, it should work > with opcode > >> caching systems (although I only know for sure that it > works with Zend > >> Accelerator). > >> > >> BTW: One key difference in performance might be due to > opcode caching, > >> especially with an application that uses Zend Framework's > files - that > >> is allot of include files to read / compile on every request. > >> > >> When you use opcode cache (like Matthew does) the time of reading / > >> compiling include files drops to (almost) zero. I'm quite sure your > >> shared hosting provider doesn't provide opcode caching - > especially if > >> you use CGI PHP and not SAPI / FastCGI PHP. > >> > >> It would be interesting to benchmark the time it takes to process a > >> request with / without opcode cache. > >> > >> Shahar. > >> > > >
