In the performance guide it says
"Define your Zend Framework include_path as early as possible
Continuing from the previous suggestion, another obvious optimization is to
define your Zend Framework include_path as early as possible in your
include_path. In most cases, it should be the first path in the list. This
ensures that files included from Zend Framework are found on the first
scan."
If ZF library is set prior to execution and we then set application level
include paths the include_path will read:
1. application level set include_path (application/library)
2. include_path set prior to execution (ZF)
Shouldn't this be the other way round?
Is this a trivial performance cost?
If this is not a trivial performance cost would it good to have an option in
Zend_Application to append application level include paths rather than
prepend them when setting the include path?
Zend_Application lines 227-232
public function setIncludePaths(array $paths)
{
$path = implode(PATH_SEPARATOR, $paths);
set_include_path($path . PATH_SEPARATOR . get_include_path());
return $this;
}
to something like:
public function setIncludePaths(array $paths)
{
$path = implode(PATH_SEPARATOR, $paths);
if ($this->getOption('appendIncludePaths')) {
$includePath = $path . PATH_SEPARATOR . get_include_path();
} else {
$includePath = get_include_path() . PATH_SEPARATOR . $path;
}
set_include_path($includePath);
return $this;
}
we could the set it in our config file.
e.g. ini would read:
includePaths.library = APPLICATION_PATH "/../library"
appendIncludePaths = true
Matthew Weier O'Phinney-3 wrote:
>
> -- Rob Allen <[email protected]> wrote
> (on Friday, 24 April 2009, 06:23 AM +0100):
>> On 23 Apr 2009, at 23:42, Matthew Weier O'Phinney wrote:
>> > That said, we're seeing some momentum by shared hosts as well as
>> > xAMP stacks to include ZF in the default include_path (Zend Server
>> > falls in this category as well). In such cases, you may be able to
>> > bootstrap your ZF application and still use your preferred version
>> > of ZF by adding your include_path.
>> >
>> > One sitation we considered was having Zend_Application add a minimal
>> > include_path to ensure that your ZF include_path includes the path in
>> > which it is found, if that makes sense. Basically, in the constructor,
>> > we'd do something like this:
>> >
>> > $localPath = realpath(dirname(__FILE__) . '/../');
>> > set_include_path($localPath . PATH_SEPARATOR . get_include_path());
>> >
>> > The problem with this is that it's horribly inefficient if you
>> > already have ZF on your include_path, and adds overhead on every
>> > call. We opted to drop it in order to keep bootstrapping as
>> > performant as possible.
>>
>> Does this imply that you (the ZF team) believe that best practice ZF
>> sites do not need the library/ directory on their include_path now?
>
> Not at all. The implications are:
>
> * It's better to set your include_path at the vhost (preferred) or
> htaccess (second best) level. For performance reasons, these are the
> better locations.
>
> * Having a library/ directory is going to be useful whenever you have
> custom libraries or other 3rd party libraries (including ZF) that
> your application will use.
>
> The primary implication is quite simply that the include_path should be
> set prior to execution whenever possible.
>
> --
> Matthew Weier O'Phinney
> Project Lead | [email protected]
> Zend Framework | http://framework.zend.com/
>
>
--
View this message in context:
http://www.nabble.com/Zend_Application-Bootstrapping-tp23145548p23237042.html
Sent from the Zend Framework mailing list archive at Nabble.com.
