http://blog.quantum-star.com
http://www.patternsforphp.com
P.S. Hope everyone had a great Christmas and New Year!
- Original Message
From: titerm [EMAIL PROTECTED]
To: fw-general@lists.zend.com
Sent: Tuesday, January 9, 2007 10:24:19 PM
Subject: Re: [fw-general] ZF and Autoloading
IMHO
If I may chime in and ask, what -- if any -- problems could arise from
wrapping each require/require_once with a condition to see if __autoload()
is defined?
For example, in my bootstrap I do the following:
function __autoload($className) {
Zend::loadClass($className);
}
And then in every
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Unless the opcache is smart enough to optimize the if block you are
never going to get the full benefit of the opcode cache as you are
conditionally including files.
Ken Stanley wrote:
If I may chime in and ask, what -- if any -- problems could
In my opinion, discussing adding autoloading at this stage rates as
premature optimisation. As someone else noted, we're making educated
autoloading is not an optimization. It's not a performance feature (it
can be more or less performing depending on how many classes you have,
how they are
Unless the opcache is smart enough to optimize the if block you are
never going to get the full benefit of the opcode cache as you are
conditionally including files.
Actually I don't see any reason why conditional include would hurt
performance in any way - it shouldn't hurt compile-time
Because the require_once() is conditional, it's not actually seen as a
straight forward include (you can't predict whether to require the file
until that code block is executed). As a result, although the file is
cached, the class/etc. in it are done so separate to the main code. Net
result is
Hi,
I think that I speak for everybody when I thank you for this clear
explanation. I've got a small question still. (I hope it is the last)
Is compile-time binding for class B done in script:
require('a.php');// defines class A
class B extends A { /*code*/ }
And in:
Is compile-time binding for class B done in script:
require('a.php');// defines class A
class B extends A { /*code*/ }
No, won't bind (unless some tool loads a.php in compile-time once it
parses 'require' - I don't know about any tools that do that, it's very
hard to do it IMHO)
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Hi All,
Rob Marscher wrote:
I think part of the concern with adding autoload directly into the
framework is that developers might want their autoload function to
include additional logic to allow it to work with their other
libraries.
As
Ok, so here is the thing, while autoloading might be cool and fun it
doesn't work with OpCaches...
Let me rephrase that, Your code will work but you will not see the
full use of the opcache, this has been discussed in detail on the pear
mailing lists and a couple other places.
Basically when
Check out some of the discussions you will find here
http://www.google.com/search?hl=enlr=q=autoload+opcachebtnG=Search
Specific place to look is http://news.php.net/php.apc.dev/9
Also bug report
http://pecl.php.net/bugs/bug.php?id=8765
A comment that sticks out
Using __autoload and
Again, the following statement from Rasmus contradicts with the statement
made by Lars above (using XCache) who says, You can see cached files in the
stats which are just loaded via autoload:
It boils down to the fact that anything you push down into the executor is
going
to be slower than
What we need is a conclusive clarification on various op-caches and their
behaviors.
On 1/9/07, Shekar C Reddy [EMAIL PROTECTED] wrote:
Again, the following statement from Rasmus contradicts with the statement
made by Lars above (using XCache) who says, You can see cached files in the
stats
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I think the key issue here is 'taking full advantage of opcaches'. From
what I have read[1] autoload will work with an opcache however it will
not be as fast as a script that does a number of require calls to static
filenames.
Now I assume that
These are tests that were done for Propel, note that propel has now
gone to requiring spl_autoload because of these results.
this is using eaccel as apc was crashing for him, php 5.0.4, october 4th
(02:38:26) let's see if it crashes my apache like APC does
(02:38:35) nope!
(02:38:41) shit
The file itself can be cached but its cached as a seperate entity, to
be included on demand, it is not cached as a part of your main code.
What this means is instead of ending up with a single large opcache
compiled version you end up with a smaller main block and all your
autoloaded blocks.
I disagree with it not making sense, if there are less objects in
memory when you are trying to initialize the next required object the
engine will be able to find it quicker. Seems to be the case at least.
These results were ran multiple times and got the same numbers. The
only files required
Using __autoload and require_once basically destroys any advantage apc
is likely to bring you. Mainly because you move the compilation sequence
into mid-runtime land, where the engine stops execution and proceeds to
compile stuff.
I can't make any sense out of it, frankly. Unless APC is
from autoloaded class (then compiler can't runtime-bind the inherited
Read: can't compile-time bind the inherited class
class) but if you use autoloading on new(), etc. it doesn't matter at all.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
binding) and anyway it only comes into play if you, for example, inherit
from autoloaded class (then compiler can't runtime-bind the inherited
class) but if you use autoloading on new(), etc. it doesn't matter at all.
Additionally, the non-autoloading example works better only in case like:
Arnaud Limbourg wrote:
You can also have a build mechanism that removes all the require
statement and move them to one file. That way you can load all the files
you need up front, at least those you use the most.
That definitely can be done, and for some sites it might be a good
solution.
Stanislav Malyshev wrote:
Arnaud Limbourg wrote:
You can also have a build mechanism that removes all the require
statement and move them to one file. That way you can load all the
files you need up front, at least those you use the most.
That definitely can be done, and for some sites it
IMHO, the main point of autoload is not to be faster or not.
The point is not to have to maintain include directive. You are using a
class, autoload will load it.
After a while, you don't use it anymore, it won't be loaded anymore.
That's it.
I use APC for better performance, but i use also page
Hi,
Am Sonntag, den 07.01.2007, 05:00 -0500 schrieb Shekar C Reddy:
I see at least one benefit to using autoload - load classes only
as-needed. Changes to code/framework frequently need a re-visit to the
require*() calls to see if any classes are loaded superfluously. Some
classes loaded
Hi everyone.
I was playing around with the spl_autoload_register function today and
decided to ask, Why doesn't ZF use it instead of all the require_once calls?
a simple
spl_register_autoload(array('Zend', 'loadClass'));
would do the trick i think. It's valid from PHP 5 = 5.1.0RC1 (
I've actually used spl_autoload_register with the ZF with great success. One
thing you should realize though, is that when working with non-ZF code (I
use some ezComponents[1] and some of my own stuff, all of which work
wonderfully with spl_autoload_register), there will be an exception thrown
Lee Saferite wrote:
Anyway, could someone smarter than me give an intelligent reason we do
not use this function?
Tony Hoare is a very smart man, and he said: Premature optimization is
the root of all evil.
This is known as Hoare's Dictum. See
http://en.wikiquote.org/wiki/Tony_Hoare
I've seen lots of statements about using an autoloader interfering with
byte code caches. Unfortunately, my understanding of byte code caching
is limited. It would seem to me that it would cache the byte code from
each file as a separate cache entry and the world would be right. But
that's
28 matches
Mail list logo
