Reducing the number of loaded exception files

[Shahar Evron]

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.

--

Shahar.

[Darby Felton]

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.

Yes, please, such a list would be very helpful. Would you mind adding
this as list to a new JIRA issue? I'm pretty sure that in the case of
Exception class derivatives, it is decidedly best practice to lazy-load
the class files just before throwing an exception. They are exceptions,
after all, and should only be needed and loaded in exceptional situations.

Thanks, Shahar!

Best regards,
Darby

>
> Better suggestions are most welcome!
>
> Thanks,
>
> Shahar.
>

[Ralph Schindler]

I personally put this in the category of 'Performance Enhancement' (and
not of Viagra persuasion).

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? ;)

Hehe, all joking aside, I personally would love to see hard data on the
interactions of require_once and opcode caches.

-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.
>

[Shahar Evron]

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.
> >

[Shahar Evron]

I've auto-generated a list of Framework *core* files that prematurely
load their Exception classes and put it on the Wiki:
http://framework.zend.com/wiki/display/ZFDEV/Lazy-loading+Exceptions

The list is quite long (176 files!) so I didn't start putting it into
JIRA - perhaps there's a more efficient way than doing that manually...

I do see some of my own files in the list - so I know I'm going to work
on fixing my stuff. Others should do the same I guess.

Shahar.

On Thu, 2007-12-13 at 15:35 -0500, Darby Felton wrote:

> 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.
>
> Yes, please, such a list would be very helpful. Would you mind adding
> this as list to a new JIRA issue? I'm pretty sure that in the case of
> Exception class derivatives, it is decidedly best practice to lazy-load
> the class files just before throwing an exception. They are exceptions,
> after all, and should only be needed and loaded in exceptional situations.
>
> Thanks, Shahar!
>
> Best regards,
> Darby
>
> >
> > Better suggestions are most welcome!
> >
> > Thanks,
> >
> > Shahar.
> >

--

Shahar Evron [hidden email]
Technical Consultant
Zend Technologies

Mobile: [phone]
Office: [phone] ext. 9546

[till]

On Dec 13, 2007 9:39 PM, Ralph Schindler <[hidden email]> wrote:
> (...)
> Hehe, all joking aside, I personally would love to see hard data on the
> interactions of require_once and opcode caches.

Check this out:
<http://www.nabble.com/Benchmark-results-for-require-vs-require_once-with-and-without-APC--28hard-numbers-for-the-allfiles.php-debate-29-to11508454.html>

PEAR is certainly not the same, but maybe alike. Also, if this thread
doesn't satisfy your hunger for the hard facts, search pear-dev (on
Google/nabble) for require_once, opcode, Allfiles.php and so on. It's
pretty interesting.

Regards,
Till

[Shekar C Reddy]

I would suggest to incorporate a method that serves as a central location to instantiate exception objects - a consistent object-instantiation system, if you will. This method could go inside a class that is always required/loaded so we don't have to include another file just for this purpose. Zend_Loader, maybe? This approach allows us to add more processing/error-handling logic to the method in future that ripples across the framework:

 

//////////////////////////////////////////////////////////////////////////
static function getException( $class, $message = 'ERROR', $code = 0, ... )
//////////////////////////////////////////////////////////////////////////
{
   self::loadClass( $class );

   //

     // Or straight require_once for performance, but then format the class-name to instantiate...

// require_once( $class );
   //
   return new $class( $message, $code, ... );
}
////////////////////////////////////////////////////////////////////////////////
 

Then, from within the code where an exception needs to be thrown, this becomes just a simple one-liner, instead of spilling require_once/etc lines of code all over the framework:

 

throw Zend_Loader::getException( <class>, <message>, <code>, ... );

 

 

2. On another note, how about other class-files that get included superfluously? I'm quite sure there are an awful lot of files included in the framework's classes without ever being used. ViewRenderer.php is just an example. If we really want to reduce the number of included files to improve performance, we need to work on these ones, too. Bottom line - include files only on a need-to-use basis and just-in-time! I, for one, don't want any files loaded that I don't want to use in my application - its just an over-head.

 

my2c

 

 

On 12/13/07, Shahar Evron <[hidden email] > 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.

--

Shahar.

[weierophinney]

-- Shekar C Reddy <[hidden email]> wrote
(on Friday, 14 December 2007, 12:50 PM -0600):

> I would suggest to incorporate a method that serves as a central location to
> instantiate exception objects - a consistent object-instantiation system, if
> you will. This method could go inside a class that is always required/loaded so
> we don't have to include another file just for this purpose. Zend_Loader,
> maybe? This approach allows us to add more processing/error-handling logic to
> the method in future that ripples across the framework:
>  
> //////////////////////////////////////////////////////////////////////////
> static function getException( $class, $message = 'ERROR', $code = 0, ... )
> //////////////////////////////////////////////////////////////////////////
> {
>    self::loadClass( $class );
>    //
>      // Or straight require_once for performance, but then format the
> class-name to instantiate...
> // require_once( $class );
>    //
>    return new $class( $message, $code, ... );
> }
> ///////////////////////////////////////////////////////////////////////////////
> /
>  
> Then, from within the code where an exception needs to be thrown, this becomes
> just a simple one-liner, instead of spilling require_once/etc lines of code all
> over the framework:
>  
> throw Zend_Loader::getException( <class>, <message>, <code>, ... );

There are *no* classes right now that get loaded by every other class;
doing so introduces unwanted coupling.

> 2. On another note, how about other class-files that get included
> superfluously? I'm quite sure there are an awful lot of files included
> in the framework's classes without ever being used. ViewRenderer.php
> is just an example.

For what it's worth, the ViewRenderer is loaded during dispatch() only
if the user has not set the 'noViewRenderer' flag; same with the
ErrorHandler plugin. Users complained about them being loaded, and we
listened. :-)

> If we really want to reduce the number of included files to improve
> performance, we need to work on these ones, too. Bottom line - include
> files only on a need-to-use basis and just-in-time! I, for one, don't
> want any files loaded that I don't want to use in my application - its
> just an over-head.

Perhaps you could go and create a list that shows these? I think in most
cases, we're not doing includes unless needed... with the exception of
exception classes, but we cannot know unless somebody produces an audit.

> On 12/13/07, Shahar Evron <[hidden email] > 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.
>
>     --
>
>     Shahar.
>
>
>

--
Matthew Weier O'Phinney
PHP Developer            | [hidden email]
Zend - The PHP Company   | http://www.zend.com/

[Ralph Schindler]

I'm just going off memory right now, but I think stack traces for
exception objects are wound up from the point which they are created,
not the point which they are thrown from.  So this would mean that when
you look at the trace from the exception, it originates from the
getException method, rather than the place you are wanting to throw it from.


-ralph

Shekar C Reddy wrote:

> I would suggest to incorporate a method that serves as a central
> location to instantiate exception objects - a *consistent
> *object-instantiation system, if you will. This method could go inside
> a class that is always required/loaded so we don't have to include
> another file just for this purpose. Zend_Loader, maybe? This approach
> allows us to add more processing/error-handling logic to the method in
> future that ripples across the framework:
>  
> //////////////////////////////////////////////////////////////////////////
> static function getException( $class, $message = 'ERROR', $code = 0, ... )
> //////////////////////////////////////////////////////////////////////////
> {
>    self::loadClass( $class );
>    //
>      // Or straight require_once for performance, but then format the
> class-name to instantiate...
> // require_once( $class );
>    //
>    return new $class( $message, $code, ... );

[Jordan Moore-2]

It's at the throw, not at instantiation.

On Dec 14, 2007 12:14 PM, Ralph Schindler <[hidden email]> wrote:

> I'm just going off memory right now, but I think stack traces for
> exception objects are wound up from the point which they are created,
> not the point which they are thrown from.  So this would mean that when
> you look at the trace from the exception, it originates from the
> getException method, rather than the place you are wanting to throw it from.
>
>
> -ralph
>
>
> Shekar C Reddy wrote:
> > I would suggest to incorporate a method that serves as a central
> > location to instantiate exception objects - a *consistent
> > *object-instantiation system, if you will. This method could go inside
> > a class that is always required/loaded so we don't have to include
> > another file just for this purpose. Zend_Loader, maybe? This approach
> > allows us to add more processing/error-handling logic to the method in
> > future that ripples across the framework:
> >
> > //////////////////////////////////////////////////////////////////////////
> > static function getException( $class, $message = 'ERROR', $code = 0, ... )
> > //////////////////////////////////////////////////////////////////////////
> > {
> >    self::loadClass( $class );
> >    //
> >      // Or straight require_once for performance, but then format the
> > class-name to instantiate...
> > // require_once( $class );
> >    //
> >    return new $class( $message, $code, ... );
>

[sleekslush]

Why not just implement the __autoload function and handle the require_once for the Exception class there?

On Dec 14, 2007 4:19 PM, Jordan Moore <[hidden email]> wrote:

It's at the throw, not at instantiation.

On Dec 14, 2007 12:14 PM, Ralph Schindler <[hidden email]> wrote:

> I'm just going off memory right now, but I think stack traces for
> exception objects are wound up from the point which they are created,
> not the point which they are thrown from.  So this would mean that when
> you look at the trace from the exception, it originates from the
> getException method, rather than the place you are wanting to throw it from.
>
>
> -ralph
>
>
> Shekar C Reddy wrote:
> > I would suggest to incorporate a method that serves as a central
> > location to instantiate exception objects - a *consistent
> > *object-instantiation system, if you will. This method could go inside
> > a class that is always required/loaded so we don't have to include
> > another file just for this purpose. Zend_Loader, maybe? This approach
> > allows us to add more processing/error-handling logic to the method in
> > future that ripples across the framework:
> >
> > //////////////////////////////////////////////////////////////////////////
> > static function getException( $class, $message = 'ERROR', $code = 0, ... )
> > //////////////////////////////////////////////////////////////////////////
> > {
> >    self::loadClass( $class );
> >    //
> >      // Or straight require_once for performance, but then format the
> > class-name to instantiate...
> > // require_once( $class );
> >    //
> >    return new $class( $message, $code, ... );
>

--
Craig Slusher
[hidden email]

[Ralph Schindler]

I wish that were the case, but not so much.

We actually did have this functionality, and removed it for various
reasons, you can look back at this post:

http://www.nabble.com/Re-3A-Do-we-really-need-Zend-3A-3Aexception-28-29--to7929347s16154.html#a7929347

for conclusions.

As for the code behind stacks, hope this helps:



C:\Documents and Settings\rschindler\My Documents\tests>cat etest.php
<?php

class E_Factory
{
   static public function getException()
   {
     $e = new Exception();
     return $e;
   }
}

class E_Thrower
{
   public function sayEFactory()
   {
     throw E_Factory::getException();
   }
   public function sayE()
   {
     throw new Exception();
   }
}


$c = new E_Thrower();

echo 'From factory - getLine() says: ';

try {
   $c->sayEFactory();
} catch (Exception $e) {
   echo $e->getLine();
}

echo PHP_EOL . 'From direct  getLine() says: ';

try {
   $c->sayE();
} catch (Exception $e) {
   $t = $e->getTrace();
   echo $e->getLine();
}

C:\Documents and Settings\rschindler\My Documents\tests>php etest.php
 From factory - getLine() says: 7
 From direct  getLine() says: 20


This was also actually implemented at one point, then we took it out for
that exact reason.



Jordan Moore wrote:

> It's at the throw, not at instantiation.
>
> On Dec 14, 2007 12:14 PM, Ralph Schindler <[hidden email]> wrote:
>> I'm just going off memory right now, but I think stack traces for
>> exception objects are wound up from the point which they are created,
>> not the point which they are thrown from.  So this would mean that when
>> you look at the trace from the exception, it originates from the
>> getException method, rather than the place you are wanting to throw it from.
>>
>>
>> -ralph
>>
>>
>> Shekar C Reddy wrote:
>>> I would suggest to incorporate a method that serves as a central
>>> location to instantiate exception objects - a *consistent
>>> *object-instantiation system, if you will. This method could go inside
>>> a class that is always required/loaded so we don't have to include
>>> another file just for this purpose. Zend_Loader, maybe? This approach
>>> allows us to add more processing/error-handling logic to the method in
>>> future that ripples across the framework:
>>>
>>> //////////////////////////////////////////////////////////////////////////
>>> static function getException( $class, $message = 'ERROR', $code = 0, ... )
>>> //////////////////////////////////////////////////////////////////////////
>>> {
>>>    self::loadClass( $class );
>>>    //
>>>      // Or straight require_once for performance, but then format the
>>> class-name to instantiate...
>>> // require_once( $class );
>>>    //
>>>    return new $class( $message, $code, ... );
>

[Shekar C Reddy]

Matthew,

 

Zend_Controller_Front.php has the following lines of code on the top instead of conditionally requiring them in dispatch():

 

/** Zend_Controller_Action_Helper_ViewRenderer */
require_once 'Zend/Controller/Action/Helper/ViewRenderer.php';

/** Zend_Controller_Plugin_ErrorHandler */
require_once 'Zend/Controller/Plugin/ErrorHandler.php';
 

 

For those who don't use ViewRenderer and ErrorHandler, these files still get included on each page-load unless they are moved into dispatch() to require them conditionally:

 

http://framework.zend.com/issues/browse/ZF-2313

 

Regards,

 

 

 

On 12/14/07, Matthew Weier O'Phinney <[hidden email]> wrote:

-- Shekar C Reddy <[hidden email]> wrote
(on Friday, 14 December 2007, 12:50 PM -0600):

> I would suggest to incorporate a method that serves as a central location to
> instantiate exception objects - a consistent object-instantiation system, if
> you will. This method could go inside a class that is always required/loaded so
> we don't have to include another file just for this purpose. Zend_Loader,
> maybe? This approach allows us to add more processing/error-handling logic to
> the method in future that ripples across the framework:
>
> //////////////////////////////////////////////////////////////////////////
> static function getException( $class, $message = 'ERROR', $code = 0, ... )
> //////////////////////////////////////////////////////////////////////////
> {
>    self::loadClass( $class );
>    //
>      // Or straight require_once for performance, but then format the
> class-name to instantiate...
> // require_once( $class );
>    //
>    return new $class( $message, $code, ... );
> }
> ///////////////////////////////////////////////////////////////////////////////
> /
>
> Then, from within the code where an exception needs to be thrown, this becomes
> just a simple one-liner, instead of spilling require_once/etc lines of code all
> over the framework:
>
> throw Zend_Loader::getException( <class>, <message>, <code>, ... );

There are *no* classes right now that get loaded by every other class;
doing so introduces unwanted coupling.

> 2. On another note, how about other class-files that get included
> superfluously? I'm quite sure there are an awful lot of files included
> in the framework's classes without ever being used. ViewRenderer.php
> is just an example.

For what it's worth, the ViewRenderer is loaded during dispatch() only
if the user has not set the 'noViewRenderer' flag; same with the
ErrorHandler plugin. Users complained about them being loaded, and we
listened. :-)

> If we really want to reduce the number of included files to improve
> performance, we need to work on these ones, too. Bottom line - include
> files only on a need-to-use basis and just-in-time! I, for one, don't
> want any files loaded that I don't want to use in my application - its
> just an over-head.

Perhaps you could go and create a list that shows these? I think in most
cases, we're not doing includes unless needed... with the exception of
exception classes, but we cannot know unless somebody produces an audit.

> On 12/13/07, Shahar Evron <[hidden email] > 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.
>
>     --
>
>     Shahar.
>
>
>

--
Matthew Weier O'Phinney
PHP Developer            | [hidden email]
Zend - The PHP Company   | <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.zend.com/" target="_blank">http://www.zend.com/

[weierophinney]

-- Shekar C Reddy <[hidden email]> wrote
(on Friday, 14 December 2007, 08:43 PM -0600):

> Zend_Controller_Front.php has the following lines of code on the top instead of
> conditionally requiring them in dispatch():
>  
> /** Zend_Controller_Action_Helper_ViewRenderer */
> require_once 'Zend/Controller/Action/Helper/ViewRenderer.php';
>
> /** Zend_Controller_Plugin_ErrorHandler */
> require_once 'Zend/Controller/Plugin/ErrorHandler.php';
>  
>  
> For those who don't use ViewRenderer and ErrorHandler, these files still get
> included on each page-load unless they are moved into dispatch() to require
> them conditionally:
>  
> http://framework.zend.com/issues/browse/ZF-2313

Noted -- thanks for the report. Fixed in SVN.

> On 12/14/07, Matthew Weier O'Phinney <[hidden email] > wrote:
>
>     -- Shekar C Reddy < [hidden email]> wrote
>     (on Friday, 14 December 2007, 12:50 PM -0600):
>     > I would suggest to incorporate a method that serves as a central location
>     to
>     > instantiate exception objects - a consistent object-instantiation system,
>     if
>     > you will. This method could go inside a class that is always required/
>     loaded so
>     > we don't have to include another file just for this purpose. Zend_Loader,
>     > maybe? This approach allows us to add more processing/error-handling
>     logic to
>     > the method in future that ripples across the framework:
>     >
>     > /////////////////////////////////////////////////////////////////////////
>     /
>     > static function getException( $class, $message = 'ERROR', $code = 0, ...
>     )
>     > /////////////////////////////////////////////////////////////////////////
>     /
>     > {
>     >    self::loadClass( $class );
>     >    //
>     >      // Or straight require_once for performance, but then format the
>     > class-name to instantiate...
>     > // require_once( $class );
>     >    //
>     >    return new $class( $message, $code, ... );
>     > }
>     > /////////////////////////////////////////////////////////////////////////
>     //////
>     > /
>     >
>     > Then, from within the code where an exception needs to be thrown, this
>     becomes
>     > just a simple one-liner, instead of spilling require_once/etc lines of
>     code all
>     > over the framework:
>     >
>     > throw Zend_Loader::getException( <class>, <message>, <code>, ... );
>
>     There are *no* classes right now that get loaded by every other class;
>     doing so introduces unwanted coupling.
>
>     > 2. On another note, how about other class-files that get included
>     > superfluously? I'm quite sure there are an awful lot of files included
>     > in the framework's classes without ever being used. ViewRenderer.php
>     > is just an example.
>
>     For what it's worth, the ViewRenderer is loaded during dispatch() only
>     if the user has not set the 'noViewRenderer' flag; same with the
>     ErrorHandler plugin. Users complained about them being loaded, and we
>     listened. :-)
>
>     > If we really want to reduce the number of included files to improve
>     > performance, we need to work on these ones, too. Bottom line - include
>     > files only on a need-to-use basis and just-in-time! I, for one, don't
>     > want any files loaded that I don't want to use in my application - its
>     > just an over-head.
>
>     Perhaps you could go and create a list that shows these? I think in most
>     cases, we're not doing includes unless needed... with the exception of
>     exception classes, but we cannot know unless somebody produces an audit.
>
>
>     > On 12/13/07, Shahar Evron < [hidden email] > 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.
>     >
>     >     --
>     >
>     >     Shahar.
>     >
>     >
>     >
>
>     --
>     Matthew Weier O'Phinney
>     PHP Developer            | [hidden email]
>     Zend - The PHP Company   | http://www.zend.com/
>
>

--
Matthew Weier O'Phinney
PHP Developer            | [hidden email]
Zend - The PHP Company   | http://www.zend.com/

[Nico Edtinger-2]

Shahar Evron wrote:
> 10 redundant include files have quite an impact on performance,
> especially in places where you have no opcode cache installed.

If you don't have an opcode cache you simply don't care about  
performance. So why should we optimize for these people? There're a  
couple of opcode caches available  and future PHP versions have APC  
bundled.

The suggested optimization can be
a) something like we did before - one central method, which didn't  
work so well
b) repeated every time we need to throw an exception, which is bad  
practice and bad for readability

IMO the best solution is a big banner "USE AN OPCODE CACHE IF YOU CARE  
ABOUT PERFORMANCE".

nico

[Shahar Evron]

Hi Nico,

On Sat, 2007-12-15 at 16:54 +0100, Nico Edtinger wrote:
> Shahar Evron wrote:
> > 10 redundant include files have quite an impact on performance,
> > especially in places where you have no opcode cache installed.
>
> If you don't have an opcode cache you simply don't care about  
> performance. So why should we optimize for these people?

That's not true - some people (actually much more than "some") run in
shared hosting environments where they have no control on what PHP
extensions are installed.

Also, IMHO we build a framework, and it should be used by *users* who
*do not need to care* about much. The whole essence of frameworks is
like saying "I'll take care of this issue for you, so you don't have to
care about that".

Besides, even when you have opcode cache, requiring exception classes
which are *never* used in normal situations (that's why it's an
*exception*) has it's overhead on both performance and memory usage.
Zend Framework is not a lightweight addition to any app - and whatever
we can reduce should be reduced (again, not saying it's top priority,
but we should keep it in mind IMHO).

> and future PHP versions have APC bundled.

That should be "will have", in god knows how much time. PHP 6.0 is *at
least* a year away, and I think that's an understatement.

> The suggested optimization can be
> a) something like we did before - one central method, which didn't  
> work so well

As said, that didn't work very well.

> b) repeated every time we need to throw an exception, which is bad  
> practice and bad for readability

While I wish there was a better solution, it's not that bad IMHO. One
extra line of code per "throw" call for us is a small price to pay for
the overhead of loading almost-never used classes into memory.
Personally I don't think it has any effect on readability.

>
> IMO the best solution is a big banner "USE AN OPCODE CACHE IF YOU CARE  
> ABOUT PERFORMANCE".
>

Opcode cache does not solve all problems yet. Also, as I said before,
not all people can use opcode cache.

Shahar.

> nico

[Philip Gabbert]

On Dec 15, 2007 3:43 PM, Shahar Evron <[hidden email]> wrote:

> Hi Nico,
>
> On Sat, 2007-12-15 at 16:54 +0100, Nico Edtinger wrote:
> > Shahar Evron wrote:
> > > 10 redundant include files have quite an impact on performance,
> > > especially in places where you have no opcode cache installed.
> >
> > If you don't have an opcode cache you simply don't care about
> > performance. So why should we optimize for these people?
>
> That's not true - some people (actually much more than "some") run in
> shared hosting environments where they have no control on what PHP
> extensions are installed.
>
> Also, IMHO we build a framework, and it should be used by *users* who
> *do not need to care* about much. The whole essence of frameworks is
> like saying "I'll take care of this issue for you, so you don't have to
> care about that".
>

As a user and developer, I'm going to have to agree with Shahar here.
Majority of your users are going to be on shared servers where they do
not have control of what caching, if any, is installed. A framework
that is meant to be used by users (think RoR) needs to be as optimized
as possible by the original coders. Simply saying "use opcode caching"
is a poor excuse for poorly developed code.

This is just my opinion as a developer...btw, this message might not
make it to the fw-core list as I don't believe I'm on it.

--
Philip
[hidden email]
http://www.gpcentre.net/

[wllm]

Hey guys, sorry I didn't get a chance to reply to this thread until now.
While I might not be an expert on performance tuning in PHP, I believe
there are a few best practices that apply to all languages and
frameworks out there. Foremost among these is never increase code
complexity before having reasonable benchmarks to give you a decent
'before' and 'after' picture of the optimization. I realize that PHP is
somewhat unique in the benefit it can realize from an opcode cache, so I
would expect these figures for both opcode-cached and -uncached
installations. I also realize the extent of the complexity that might be
introduced- in fact, we might be able to simplify the lazy-loading of
exception classes further by introducing a factory method- possibly in
the Zend_Loader class- which doesn't make for a whole hell of a lot of
complexity. That said, it does add SOME complexity to the framework,
since we either have to include the exception class in more places than
we had to previously or we would have to prescribe a different method of
exception class loading than the most basic suggested usage at the
language level, and is therefore subject to the rule of thumb I mention
above.
Fortunately, we plan to do a performance audit of framework in the 1.5
timeframe that will create exactly these benchmarks to test against
going forward. ;D While I imagine that these will support a strong
argument for lazy loading of exceptions, I suggest we wait until we've
had a chance to run these benchmarks to decide which optimizations of
the many possibilities that we agree are worth the extra complexity.
Ultimately, this is another argument against 'premature optimization',
but I'm being slightly more specific about the definition of 'premature'
here- anything before our 1.5 performance tests are executed and the
results compiled. :)

Thanks.
,Wil

> -----Original Message-----
> From: Philip G [mailto:[hidden email]]
> Sent: Saturday, December 15, 2007 2:17 PM
> To: fw-general; fw-core
> Subject: Re: [fw-general] Reducing the number of loaded exception
files

>
> On Dec 15, 2007 3:43 PM, Shahar Evron <[hidden email]> wrote:
> > Hi Nico,
> >
> > On Sat, 2007-12-15 at 16:54 +0100, Nico Edtinger wrote:
> > > Shahar Evron wrote:
> > > > 10 redundant include files have quite an impact on performance,
> > > > especially in places where you have no opcode cache installed.
> > >
> > > If you don't have an opcode cache you simply don't care about
> > > performance. So why should we optimize for these people?
> >
> > That's not true - some people (actually much more than "some") run

in
> > shared hosting environments where they have no control on what PHP
> > extensions are installed.
> >
> > Also, IMHO we build a framework, and it should be used by *users*
who

> > *do not need to care* about much. The whole essence of frameworks is
> > like saying "I'll take care of this issue for you, so you don't have
> to
> > care about that".
> >
>
> As a user and developer, I'm going to have to agree with Shahar here.
> Majority of your users are going to be on shared servers where they do
> not have control of what caching, if any, is installed. A framework
> that is meant to be used by users (think RoR) needs to be as optimized
> as possible by the original coders. Simply saying "use opcode caching"
> is a poor excuse for poorly developed code.
>
> This is just my opinion as a developer...btw, this message might not
> make it to the fw-core list as I don't believe I'm on it.
>
> --
> Philip
> [hidden email]
> http://www.gpcentre.net/

[Eric Coleman-3]

When and where will these results be published?

Regards,
Eric

On Dec 15, 2007, at 9:58 PM, Wil Sinclair wrote:

> Hey guys, sorry I didn't get a chance to reply to this thread until  
> now.
> While I might not be an expert on performance tuning in PHP, I believe
> there are a few best practices that apply to all languages and
> frameworks out there. Foremost among these is never increase code
> complexity before having reasonable benchmarks to give you a decent
> 'before' and 'after' picture of the optimization. I realize that PHP  
> is
> somewhat unique in the benefit it can realize from an opcode cache,  
> so I
> would expect these figures for both opcode-cached and -uncached
> installations. I also realize the extent of the complexity that  
> might be
> introduced- in fact, we might be able to simplify the lazy-loading of
> exception classes further by introducing a factory method- possibly in
> the Zend_Loader class- which doesn't make for a whole hell of a lot of
> complexity. That said, it does add SOME complexity to the framework,
> since we either have to include the exception class in more places  
> than
> we had to previously or we would have to prescribe a different  
> method of
> exception class loading than the most basic suggested usage at the
> language level, and is therefore subject to the rule of thumb I  
> mention
> above.
> Fortunately, we plan to do a performance audit of framework in the 1.5
> timeframe that will create exactly these benchmarks to test against
> going forward. ;D While I imagine that these will support a strong
> argument for lazy loading of exceptions, I suggest we wait until we've
> had a chance to run these benchmarks to decide which optimizations of
> the many possibilities that we agree are worth the extra complexity.
> Ultimately, this is another argument against 'premature optimization',
> but I'm being slightly more specific about the definition of  
> 'premature'
> here- anything before our 1.5 performance tests are executed and the
> results compiled. :)
>
> Thanks.
> ,Wil
>
>> -----Original Message-----
>> From: Philip G [mailto:[hidden email]]
>> Sent: Saturday, December 15, 2007 2:17 PM
>> To: fw-general; fw-core
>> Subject: Re: [fw-general] Reducing the number of loaded exception
> files
>>
>> On Dec 15, 2007 3:43 PM, Shahar Evron <[hidden email]> wrote:
>>> Hi Nico,
>>>
>>> On Sat, 2007-12-15 at 16:54 +0100, Nico Edtinger wrote:
>>>> Shahar Evron wrote:
>>>>> 10 redundant include files have quite an impact on performance,
>>>>> especially in places where you have no opcode cache installed.
>>>>
>>>> If you don't have an opcode cache you simply don't care about
>>>> performance. So why should we optimize for these people?
>>>
>>> That's not true - some people (actually much more than "some") run
> in
>>> shared hosting environments where they have no control on what PHP
>>> extensions are installed.
>>>
>>> Also, IMHO we build a framework, and it should be used by *users*
> who
>>> *do not need to care* about much. The whole essence of frameworks is
>>> like saying "I'll take care of this issue for you, so you don't have
>> to
>>> care about that".
>>>
>>
>> As a user and developer, I'm going to have to agree with Shahar here.
>> Majority of your users are going to be on shared servers where they  
>> do
>> not have control of what caching, if any, is installed. A framework
>> that is meant to be used by users (think RoR) needs to be as  
>> optimized
>> as possible by the original coders. Simply saying "use opcode  
>> caching"
>> is a poor excuse for poorly developed code.
>>
>> This is just my opinion as a developer...btw, this message might not
>> make it to the fw-core list as I don't believe I'm on it.
>>
>> --
>> Philip
>> [hidden email]
>> http://www.gpcentre.net/

[wllm]

They will be published on the framework site in a prominent location.
Whether that is on the wiki or somewhere else has yet TBD. As for the
timing, the scope, and the format of the tests/results, we are shooting
for sometime within a few weeks after the 1.5 release, the scope would
be broad and deep enough to be useful for optimization in both ZF and
most applications (although we may or may not run other frameworks
through the same benchmarks for comparison or tests against every
component in ZF), and the format of the tests/results is entirely TBD
(you can rest assured they will be designed to reveal any areas for
improvement; we're not looking for transparency- not marketing
materials- here). In addition, we hope to establish a reusable set of
benchmarks and tests; everyone should be aware, however, that results
can't be directly compared across different environments except WRT well
defined variables such as whether an opcode cache was used or not. If
anyone has any suggestion for specific scenarios or areas we should be
testing, please post them to fw-general.

Also, I know that it has been mentioned before, but it's worth
repeating. On the framework team we seek to strike the best balance
between performance and ease of development and maintainability. If all
applications were designed with only performance in mind, we would live
in a very different technical world with far fewer innovations and a
much longer time-to-market across almost all technical domains- web
development would certainly be no exception. I believe most
battle-scarred developers and architects would tell you that the most
effective performance optimizations happen below the application
programming level (witness all the query optimization and rewriting that
happens in Oracle, for example; I can tell you that very few people know
how to or invest the time to implement these optimization in their own
queries and schemas) and that you reach the law of diminishing returns
very quickly with the cost of developer time vs. additional hardware
(hosting cost, etc.) nowadays. AFAIK, opcode caches are a perfect
example of developer-transparent performance optimization. I hope that
gives you some insight in to how we prioritize work for ZF; for Zend
Framework it means that we will be busy in the next month delivering a
lot of the features that our users have been asking for, and performance
improvements that are exposed by benchmarks may have to wait for
subsequent mini or minor releases after 1.5. That said, if anyone in the
community has a great performance improvement that they can back up with
benchmarks- especially if it is transparent to the developer- there is
still time to get it in to 1.5! :)

,Wil

> -----Original Message-----
> From: Eric Coleman [mailto:[hidden email]]
> Sent: Saturday, December 15, 2007 10:00 PM
> To: Wil Sinclair
> Cc: Philip G; fw-general; fw-core
> Subject: Re: [fw-core] RE: [fw-general] Reducing the number of loaded
> exception files
>
> When and where will these results be published?
>
> Regards,
> Eric
>
> On Dec 15, 2007, at 9:58 PM, Wil Sinclair wrote:
>
> > Hey guys, sorry I didn't get a chance to reply to this thread until
> > now.
> > While I might not be an expert on performance tuning in PHP, I
> believe
> > there are a few best practices that apply to all languages and
> > frameworks out there. Foremost among these is never increase code
> > complexity before having reasonable benchmarks to give you a decent
> > 'before' and 'after' picture of the optimization. I realize that PHP
> > is
> > somewhat unique in the benefit it can realize from an opcode cache,
> > so I
> > would expect these figures for both opcode-cached and -uncached
> > installations. I also realize the extent of the complexity that
> > might be
> > introduced- in fact, we might be able to simplify the lazy-loading

of

> > exception classes further by introducing a factory method- possibly
> in
> > the Zend_Loader class- which doesn't make for a whole hell of a lot
> of
> > complexity. That said, it does add SOME complexity to the framework,
> > since we either have to include the exception class in more places
> > than
> > we had to previously or we would have to prescribe a different
> > method of
> > exception class loading than the most basic suggested usage at the
> > language level, and is therefore subject to the rule of thumb I
> > mention
> > above.
> > Fortunately, we plan to do a performance audit of framework in the
> 1.5
> > timeframe that will create exactly these benchmarks to test against
> > going forward. ;D While I imagine that these will support a strong
> > argument for lazy loading of exceptions, I suggest we wait until
> we've
> > had a chance to run these benchmarks to decide which optimizations

of

> > the many possibilities that we agree are worth the extra complexity.
> > Ultimately, this is another argument against 'premature
> optimization',
> > but I'm being slightly more specific about the definition of
> > 'premature'
> > here- anything before our 1.5 performance tests are executed and the
> > results compiled. :)
> >
> > Thanks.
> > ,Wil
> >
> >> -----Original Message-----
> >> From: Philip G [mailto:[hidden email]]
> >> Sent: Saturday, December 15, 2007 2:17 PM
> >> To: fw-general; fw-core
> >> Subject: Re: [fw-general] Reducing the number of loaded exception
> > files
> >>
> >> On Dec 15, 2007 3:43 PM, Shahar Evron <[hidden email]> wrote:
> >>> Hi Nico,
> >>>
> >>> On Sat, 2007-12-15 at 16:54 +0100, Nico Edtinger wrote:
> >>>> Shahar Evron wrote:
> >>>>> 10 redundant include files have quite an impact on performance,
> >>>>> especially in places where you have no opcode cache installed.
> >>>>
> >>>> If you don't have an opcode cache you simply don't care about
> >>>> performance. So why should we optimize for these people?
> >>>
> >>> That's not true - some people (actually much more than "some") run
> > in
> >>> shared hosting environments where they have no control on what PHP
> >>> extensions are installed.
> >>>
> >>> Also, IMHO we build a framework, and it should be used by *users*
> > who
> >>> *do not need to care* about much. The whole essence of frameworks
> is
> >>> like saying "I'll take care of this issue for you, so you don't
> have
> >> to
> >>> care about that".
> >>>
> >>
> >> As a user and developer, I'm going to have to agree with Shahar
> here.
> >> Majority of your users are going to be on shared servers where they
> >> do
> >> not have control of what caching, if any, is installed. A framework
> >> that is meant to be used by users (think RoR) needs to be as
> >> optimized
> >> as possible by the original coders. Simply saying "use opcode
> >> caching"
> >> is a poor excuse for poorly developed code.
> >>
> >> This is just my opinion as a developer...btw, this message might

not
> >> make it to the fw-core list as I don't believe I'm on it.
> >>
> >> --
> >> Philip
> >> [hidden email]
> >> http://www.gpcentre.net/