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) s
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:
require_on
In "Paddy speek", I was referring to this blog entry which more or less
suggests (sort of conclusively unless its yet more FUD, dumped on
previous FUD, amounting to a big fat FUD in which case I give up ;))
http://pooteeweet.org/blog/538
Maybe someone enlightened can point out what's wrong wit
ssage
From: Stanislav Malyshev <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Zend Framework General
Sent: Wednesday, January 10, 2007 6:08:15 PM
Subject: Re: [fw-general] ZF and Autoloading
> Because the require_once() is conditional, it's not actually seen as a
> straight fo
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
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 bindin
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 u
m-star.com
http://www.patternsforphp.com
- Original Message
From: Ken Stanley <[EMAIL PROTECTED]>
To: fw-general@lists.zend.com
Sent: Wednesday, January 10, 2007 5:12:25 PM
Subject: Re: [fw-general] ZF and Autoloading
If I may chime in and ask, what -- if any -- problems could arise from w
-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
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 fi
fort or debate if its warranted for
some end users...
Pádraic Brady
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, Ja
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
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 mig
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. Tho
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.
Arnaud.
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:
ma
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/
"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 total
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 wer
That doesn't even make common sense, autoload will never be faster
then straight require if the exact same number of files are called
each time, there is less overhead.
The only way for them to get the below results would of been to
include every file in propel straight out even if it wasn't used
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.
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
(02
When i look in my APC system cache entry, i can see that every php
(main or included) is cached.
So when file is loaded, it is compile, then op-code is saved. Next
time, it ll be loaded from cache.
May be all entry will not be generated the first time, but that s the
same if you are doing incl
-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 a
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
stat
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 t
Check out some of the discussions you will find here
http://www.google.com/search?hl=en&lr=&q=autoload+opcache&btnG=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 requi
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 you
-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.
This topic has come up a few other times on this list in the last few
months so I thought I'd try to sumarize some of those points on this issue:
Arnoud Limbourg posted a link in the "Do we really need
Zend::exception()?" thread to this blog which seems to have the most
convincing evidence I'v
I'm using sp_autoload with APC on a pretty loaded site without any
problem.
Require_once/include_once is really slow... even if it s better in 5.2,
it s still really slower than require or include. Autoload allow you to
use basic include or require instead of the 'once' version.
So, even if th
Hi,
Am Sonntag, den 07.01.2007, 13:07 -0800 schrieb Charles:
[...]
> It seems that using autoload would lower the barrier-to-entry to using
> ZF (if just a little), and eliminate a whole class of problems that
> will otherwise be posted about ad-infinitum on this and other lists.
>
> Even if using
Hello,
My expertise is more product management/marketing than programming (I guess I'm
one of those "enthusiasts" who needs a pretty deep understanding of technology
to do my job), but here's my 2 cents.
It seems that using autoload would lower the barrier-to-entry to using ZF (if
just a littl
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 s
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
superfluously could load additional classes that may also be superfluous in
a
Well, i have used __autoload with my projects without any issues, and I use
byte code caches (Zend Platform, APC, and XCache). I was mainly mentioning
it since I had seen people arguing that it wouldn't work right. As for
premature optimization... When I started my current project using the ZF
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 m
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
Don
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
(by
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 (
http:/
40 matches
Mail list logo
