-- Andi Gutmans <[EMAIL PROTECTED]> wrote (on Thursday, 30 November 2006, 06:27 PM -0800): > 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.
While I agree with this in most cases, there are occasions where it makes sense: the front controller and the server components (xmlrpc server, rest, etc.); doing the isReadable() check allows us to throw an exception instead of a PHP E_FATAL, and thus still return a response to the client (in the server examples, a fault response; in the front controller, perhaps an error page). > > -----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. > > >> > > > > > > -- Matthew Weier O'Phinney PHP Developer | [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
