[fw-general] RE: [fw-core] RE: [fw-general] Reducing the number of loaded exception files

[Kaloyan K. Tzvetkov]

I know that ZF strives to provide a balance between powerful tools and easy
of use. However, reading this thread and others like it, it seems to me that
there are two approaches "battling" here ;) The first one is the one
concerning small to medium, shared hosting applications, while the other is
for the considerably larger projects, projects with dedicated (or more
sophisticated) hosting. In this thread clearly we can see the positions:

* shared-hosting ZF projects are expected to be harmed by "hardcoded"
includes, because having all those exception files loaded is not necessary
and seems like overhead; those are projects that run in environment with no
opcode cache solution available (as more or at least some of the shared
hosting providers).

* ZF projects flexing opcode caching solutions are expected to me harmed by
"conditional" includes, because they will not be picked up by the opcode
caching.

I think there are other areas in ZF like this as well. What I propose is to
consider forking ZF into 2 "versions" - one that suites best the
shared-hosting projects (small and medium projects) and one for the
dedicated projects (large, enterprise projects). It is probably too early
for a split like that, but at least it is worth discussing it: this seems
like a very sane choice, because each "version" will be true to the purpose
it is going to be used for. The API will be the same, just the
implementation of certain parts will differ slightly to fit best the
environment the library will be used in.

What do you think ?

-
K.


Regards,

Kaloyan K. Tsvetkov

http://kaloyan.info/blog/ http://kaloyan.info/blog/ 
-- 
View this message in context: 
http://www.nabble.com/Reducing-the-number-of-loaded-exception-files-tp14324215s16154p14566139.html
Sent from the Zend Framework mailing list archive at Nabble.com.

[fw-general] RE: [fw-core] RE: [fw-general] Reducing the number of loaded exception files

[Simone Carletti]

Sorry to resurrect this old post, 
but I need a final feedback.

I'm sure I posted this request before, but the email was probably refused by
Nabble.

Wil, do you confirm the last (and definitive for now) suggestion is to hold
on, waiting for more performance tests?
If so, I would suggest to post a comment or add a note to current wiki page
http://framework.zend.com/wiki/display/ZFDEV/Lazy-loading+Exceptions

-- Simone


wllm wrote:
> 
> 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:[EMAIL PROTECTED]
>> 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 f

Re: [fw-general] Reducing the number of loaded exception files

[Nico Edtinger]

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 

[fw-general] RE: [fw-core] RE: [fw-general] Reducing the number of loaded exception files

[Wil Sinclair]

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:[EMAIL PROTECTED]
> 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
> w

[fw-general] Re: [fw-core] RE: [fw-general] Reducing the number of loaded exception files

[Eric Coleman]

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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
http://www.gpcentre.net/

RE: [fw-general] Reducing the number of loaded exception files

[Wil Sinclair]

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:[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]
> http://www.gpcentre.net/

Re: [fw-general] Reducing the number of loaded exception files

[Philip G]

On Dec 15, 2007 3:43 PM, Shahar Evron <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
http://www.gpcentre.net/

Re: [fw-general] Reducing the number of loaded exception files

[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 


signature.asc
Description: This is a digitally signed message part

Re: [fw-general] Re: [fw-core] Re: [fw-general] Reducing the number of loaded exception files

[Matthew Weier O'Phinney]

-- Shekar C Reddy <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > wrote:
> 
> -- Shekar C Reddy < [EMAIL PROTECTED]> 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( , , , ... );
> 
> 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 < [EMAIL PROTECTED] > 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:
> >
> >  > if ($error_happened) {
> >require_once 'Zend/Http/Client/Exception.php';
> >throw new Zend_Http_Client_Exception('Good news, everyone!');
> > }
> > ?>
> >
> > 

[fw-general] Re: [fw-core] Re: [fw-general] Reducing the number of loaded exception files

[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 <[EMAIL PROTECTED] > wrote:
>
> -- Shekar C Reddy < [EMAIL PROTECTED]> 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( , , , ... );
>
> 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 < [EMAIL PROTECTED] > 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:
> >
> >  > 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
> > compon

Re: [fw-general] Reducing the number of loaded exception files

[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
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 <[EMAIL PROTECTED]> 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, ... );

Re: [fw-general] Reducing the number of loaded exception files

[Craig Slusher]

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 <[EMAIL PROTECTED]> wrote:

> It's at the throw, not at instantiation.
>
> On Dec 14, 2007 12:14 PM, Ralph Schindler <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]

Re: [fw-general] Reducing the number of loaded exception files

[Jordan Moore]

It's at the throw, not at instantiation.

On Dec 14, 2007 12:14 PM, Ralph Schindler <[EMAIL PROTECTED]> 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, ... );
>

Re: [fw-general] Reducing the number of loaded exception files

[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, ... );

Re: [fw-general] Reducing the number of loaded exception files

[Matthew Weier O'Phinney]

-- Shekar C Reddy <[EMAIL PROTECTED]> 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( , , , ... );

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 <[EMAIL PROTECTED] > 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:
> 
>  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| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

Re: [fw-general] Reducing the number of loaded exception files

[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( , , , ... );


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 <[EMAIL PROTECTED] > 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:
>
>  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.
>
>

Re: [fw-general] Reducing the number of loaded exception files

[till]

On Dec 13, 2007 9:39 PM, Ralph Schindler <[EMAIL PROTECTED]> 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:


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

Re: [fw-general] Reducing the number of loaded exception files

[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:
> > 
> >  >   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 [EMAIL PROTECTED]
Technical Consultant
Zend Technologies

Mobile: +972 54 30 99 446
Office: +972  3 75 39 500 ext. 9546



signature.asc
Description: This is a digitally signed message part

Re: [fw-general] Reducing the number of loaded exception files

[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:
> > 
> >  >   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

Re: [fw-general] Reducing the number of loaded exception files

[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:



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.

Re: [fw-general] Reducing the number of loaded exception files

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

[fw-general] 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:



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.


signature.asc
Description: This is a digitally signed message part