Hi Ralph, On Thu, 2007-12-13 at 14:39 -0600, Ralph Schindler wrote: > I personally put this in the category of 'Performance Enhancement' (and > not of Viagra persuasion). >
True.
> The overall problem is multi-faceted.. One must consider
> runtime-performance, compile-time/run-time performance, ability of
> op-code caches to interact with run-time loading of code, ability of
> IDE's and other tools to link required files not in a files main() scope.
>
> That said, I think its best we wait until after 1.5 to sit down and
> completely evaluate ZF from a performance perspective as well as
> evaluate the tooling associated with ZF (or any code for that matter)
> before we make runtime exception requirements part of the Coding Standard.
>
> Premature Optimization right? ;)
>
The optimization might be premature (perhaps) but I don't think setting
up a policy will be premature. There's no harm in saying that "this is
our standard" - we don't have to start going over the files one by one
fixing them as a high priority task.
I'd try to come up with a list, put it on JIRA or even the Wiki, and let
developers start fixing them at their own time - at least until it is
decided to be of high priority. I'd also announce this as a policy, so
that new code will follow these rules.
> Hehe, all joking aside, I personally would love to see hard data on the
> interactions of require_once and opcode caches.
>
Loading and compiling files has quite an impact on performance, and
opcode cache systems reduce the run time of apps with lots of include
files *dramatically*. I can say from personal experience (those kind of
benchmarks are my bread and butter) that you can take a "Hello World"
app based on ZF and make it 3 times faster (!!!) by simply enabling Zend
Platform's Accelerator component (and probably any other opcode cache
system, I usually don't benchmark APC and the others).
It should be noted that this is true for any heavy framework or complex
PHP app I've seen - for example, I've seen a Drupal based site go 7
times faster because of opcode cache.
Shahar.
> -ralph
>
>
>
> Shahar Evron wrote:
> > A while back ago there was an attempt to eliminate the loading of unused
> > Exception files / classes by different ZF components. I don't know what
> > happened with that discussion, but I think we should do something about
> > it.
> >
> > I've made some profiling of relatively simple ZF-based app (doesn't load
> > too many components - mostly the MVC, DB, Config, Registry etc. stuff)
> > and I've found some 10 calls to require_once to load an Exception class
> > without having a single exception thrown (that I know of - unless some
> > ZF code threw an exception and some other ZF component caught it).
> >
> > 10 redundant include files have quite an impact on performance,
> > especially in places where you have no opcode cache installed.
> >
> > A while back ago I changed Zend_Http_Client to require_once it's
> > exception classes only when about to throw an exception, something like:
> >
> > <?php
> > if ($error_happened) {
> > require_once 'Zend/Http/Client/Exception.php';
> > throw new Zend_Http_Client_Exception('Good news, everyone!');
> > }
> > ?>
> >
> > Now this might seem a bit cumbersome - but when considering the fact
> > that it's 1 line of code that never gets executed vs. always loading at
> > least one aditional file (not to mention cases where you load
> > Zend/Http/Client/Adapter/Exception.php which loads
> > Zend/Http/Client/Exception.php which loads Zend/Http/Exception.php which
> > loads Zend/Exception.php - you get the point) I think it's worth it.
> >
> > If nobody has a nicer solution to this overweight problem, I suggest all
> > component maintainers will start doing the same (this is not my idea and
> > I know some already do so).
> >
> > If you want, I can try to come up with a list of places that need to be
> > fixed.
> >
> > Better suggestions are most welcome!
> >
> > Thanks,
> >
> > Shahar.
> >
signature.asc
Description: This is a digitally signed message part
