One important thing to note is __autoload does not play well with opcode
cache last I checked.
It might be better to leave require statement and using an opcode cache.
Or have a deployment system that does a bunch of search and replace
aggregating several files into one and removing the require statements.
You would end up with one big file, adding an opcode cache on top of
that should be fast.
Arnaud.
Pádraic Brady wrote:
Hi all,
I haven't noticed any massive slowdowns on my own shared host. I might
be different than some since I use PHP 5.2 compiled as CGI on Dreamhost.
That likely speeds things up (faster require_once for example). It is
still slower than I would like by some margin though. Largely I just
accept it, even with a future 0.60 release I don't expect massive change
this early.
The main slowdown is using require_once. If you make a few runs using
XDebug you'll see it takes a large chunk of execution time. If I had to
optimise (noting this can be done outside the ZF svn with a little
automation and outside your own personal versioning system) I would
strip the require_once calls from the source code and implement an
__autoload function. If you need more than one type of autoload, there's
an SPL function to register multiple autoloaders.
http://ie.php.net/manual/en/function.spl-autoload-register.php
I haven't really thought much about it, but a build tool for PHP like
Phing can perform such code stripping quite easily before putting code
live. One would likely just need a regexp to match require_once
statements like:
$match = "/require_once '[a-zA-Z\/.]+';/";
and remove them completely, letting your code rely on __autoload or other.
I don't think there's any question this would speed things up (should
still be measured though to see by how much). On the other side of the
coin there are things being done in svn that will improve performance.
Some MVC components no longer use as much Reflection. Someone yesterday
suggested a more efficient Zend_Controller_Router_Route class for routes
which are simple static paths, e.g. http://myappdomain/login (no
variable reqs or defaults). I'm sure other things will improve in time -
premature optimisation concerns mean you can't really expect any
immediate incredible improvement until the ZF reaches a more mature state.
Regards,
Pádraic
Pádraic Brady
http://blog.quantum-star.com
http://www.patternsforphp.com
----- Original Message ----
From: David Rinaldi <[EMAIL PROTECTED]>
To: Zend Framework <fw-general@lists.zend.com>
Sent: Thursday, November 30, 2006 7:44:58 AM
Subject: Re: [fw-general] Shared server load times
6 seconds was probably a bit extreme, but it obviously took far too
long for real usability.
I agree that the framework shouldn't use __autoload by default. If it
turns out to be a faster method to include only the necessary files, I
think at least documentation should be updated to state what can be
edited to speed up the default installation (maybe a section on
potential optimizations). This is probably better addressed as 1.0
nears rather than at this time.
As for caching, splitting into cached portions would require hacking
the code more than I'd like. I actually use a single layout file and
use a view variable for including content files... I've liked the
maintainability better. In any case, the quote was from my old layout
and I haven't even decided I want it... I'll probably just remove it
for the final cut and use full page caching anyhow.
Thanks,
David
------------------------------------------------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.
<http://us.rd.yahoo.com/evt=45083/*http://advision.webevents.yahoo.com/mailbeta>
