Mathew,
Maybe, but how about doing an is_readable() ONLY in those situations and
skip it for the rest of the stuff? That might call for adding the $once default
argument to loadClass() as I suggested in another thread or maybe, even
setting a flag for the is_readable situations. I would suggest adding flags
for *autoload *(default false), *debugging *(default true), etc. inside Zend
class. If __autoload function is defined we could set the autoload flag to
true (or use *function_exists *or maybe there are better ways to sense it as
I'm not that strong in PHP), we can skip all the require_once calls inside
an if{} decision statement at the top of each ZF class (where even the
exception classes are included using require_once) and wherever refeferences
to require_once manifest:
if ( ! Zend::isAutoload()) { // or: ! function_exists(
'__autoload' )
require_once( ... )
...
}
This would satisfy those who do use and those who do not use __autoload
without really eliminating the require_once calls and without changing the
existing code drastically. The debugging var (if set to false meaning
the *production
*environment where minimal reality checks are necessary) could *optionally *be
used to skip the line that invokes is_readable() and any other
bottleneck/processing-intensive situations using another if{} decision
statement.
However, there may be better ways of satisfying one and all in a *generic *
fashion.
Regards,
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).
On 11/30/06, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:
-- 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/
