-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
changing __construct() to init() solved my first problem, thanks..
The Routing Problem:
My dirs:
|/application
/models
/views
/controllers
/httpdocs
/images
/styles
.htaccess
index.php
/library
/Zend|
Real url: http://192.168.0.99/entwicklung/trunk/httpdocs/
In my bootstrap:
Thanks, this works...
i could swear i testet this before like this...
Lee Saferite schrieb:
Well, The error message seems fairly self explanitory. Try using a
fully qualified path name.
$base = dirname(dirname(__FILE__));
$controller-setControllerDirectory($base .
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
Does anyone read this message? Can anyone give an answer?
I have some new questions:
1. I have problems when I search with phrase queries using query parser or
direct binding to the $index-find function. But If I construct a phrase query
with Zend_search_lucene API, $index-find function
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
Thanks, Thomas.
Zend_Search_Lucene uses current locale as an input string encoding.
It uses iconv('', 'ASCII//TRANSLIT', $stringValue); to transform input
string now.
So iconv takes current locale as an input string encoding.
It can be set with setlocale(LC_CTYPE, $myInputEncoding);
The
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
it should be a reasonable
comparison.
Can we please finally come to a conclusion on this subject? Test for
yourself or use these as a reference but PLEASE stop this FUD
surrounding autoload!
Cameron
__ NOD32 1967 (20070109) Information __
This message was checked by NOD32
19 matches
Mail list logo
