ZF2 speed

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

EvanDotPro
On Fri, Feb 24, 2012 at 7:11 AM, Pádraic Brady <[hidden email]> wrote:

> If there's any interest, it should be trivial to add some
> configuration of ZF2 as a benchmark target to Paul M. Jones'
> benchmarking testbed. I used it about a year ago to gain some reliable
> data on framework/language performance for an internal study (I have a
> modified fork sitting around on Github:
> https://github.com/padraic/php-framework-benchmarks/tree/benchmark-2010-03).
> Instead of relying on third hand, possibly dubious, benchmarks we'd
> have something a bit more scientific and representative of where we
> stand in relation to other frameworks and such. We really shouldn't
> have to wait for third party's to tell us what the performance is like
> when we can keep a running tab on it ourselves as the betas move us
> closer to the mark.

+1 on Paul M Jones' benchmarking testbed. I caught some of his
benchmarking frameworks talk at ZendCon, and he is, in my opinion, one
of the few people who really knows how to set up a good, fair baseline
benchmark test.

Also, I'll just point out that the Google doc I posted is not meant to
be used as *performance* benchmark (I didn't even mention my
hardware), but merely to show which parts of the framework are taking
higher percentages of the execution time. The important data in the
spreadsheet are the ratios, not the actual microseconds. </disclaimer>

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Pádraic Brady
> +1 on Paul M Jones' benchmarking testbed. I caught some of his
> benchmarking frameworks talk at ZendCon, and he is, in my opinion, one
> of the few people who really knows how to set up a good, fair baseline
> benchmark test.

True, I basically view any benchmark not following his methodology
religiously as being suspect. There have been ample examples of small
errors and benchmarking problems once people go off doing something
differently.

> Also, I'll just point out that the Google doc I posted is not meant to
> be used as *performance* benchmark (I didn't even mention my
> hardware), but merely to show which parts of the framework are taking
> higher percentages of the execution time. The important data in the
> spreadsheet are the ratios, not the actual microseconds. </disclaimer>

I hope nobody assumed you did on an Amazon large instance ;)


--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Tomáš Fejfar
If DI is the really slow part of the framework, I think the DI specification generator is needed and fast. I can see from the benchmarks that DI takes around 20% of the time to generate. That means we can cut the request time from 500ms to something like 350 or 400. And it will also better reflect the real framework speed. I can imagine that having >500ms/request for simple app might be enough to stop considering future usage along the lines "there is only half the features in the framework now and this is a simple app, yet still it's this slow? How enormously slow will it be with my app that is double the size and should be running on final (=with more features=slower) version of the framework". 

What's your oppinion?

On Fri, Feb 24, 2012 at 4:02 PM, Pádraic Brady <[hidden email]> wrote:
> +1 on Paul M Jones' benchmarking testbed. I caught some of his
> benchmarking frameworks talk at ZendCon, and he is, in my opinion, one
> of the few people who really knows how to set up a good, fair baseline
> benchmark test.

True, I basically view any benchmark not following his methodology
religiously as being suspect. There have been ample examples of small
errors and benchmarking problems once people go off doing something
differently.

> Also, I'll just point out that the Google doc I posted is not meant to
> be used as *performance* benchmark (I didn't even mention my
> hardware), but merely to show which parts of the framework are taking
> higher percentages of the execution time. The important data in the
> spreadsheet are the ratios, not the actual microseconds. </disclaimer>

I hope nobody assumed you did on an Amazon large instance ;)


--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Marco Pivetta (Ocramius)
Well, I can only suggest you to look at
https://github.com/zendframework/zf2/blob/master/library/Zend/Di/Configuration.php#L48
What is needed there (where the todos are) is just some strategy to plug in some compiler/cache method.

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 27 February 2012 18:10, Tomáš Fejfar <[hidden email]> wrote:
If DI is the really slow part of the framework, I think the DI specification generator is needed and fast. I can see from the benchmarks that DI takes around 20% of the time to generate. That means we can cut the request time from 500ms to something like 350 or 400. And it will also better reflect the real framework speed. I can imagine that having >500ms/request for simple app might be enough to stop considering future usage along the lines "there is only half the features in the framework now and this is a simple app, yet still it's this slow? How enormously slow will it be with my app that is double the size and should be running on final (=with more features=slower) version of the framework". 

What's your oppinion?


On Fri, Feb 24, 2012 at 4:02 PM, Pádraic Brady <[hidden email]> wrote:
> +1 on Paul M Jones' benchmarking testbed. I caught some of his
> benchmarking frameworks talk at ZendCon, and he is, in my opinion, one
> of the few people who really knows how to set up a good, fair baseline
> benchmark test.

True, I basically view any benchmark not following his methodology
religiously as being suspect. There have been ample examples of small
errors and benchmarking problems once people go off doing something
differently.

> Also, I'll just point out that the Google doc I posted is not meant to
> be used as *performance* benchmark (I didn't even mention my
> hardware), but merely to show which parts of the framework are taking
> higher percentages of the execution time. The important data in the
> spreadsheet are the ratios, not the actual microseconds. </disclaimer>

I hope nobody assumed you did on an Amazon large instance ;)


--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

EvanDotPro
In reply to this post by Tomáš Fejfar
On Mon, Feb 27, 2012 at 10:10 AM, Tomáš Fejfar <[hidden email]> wrote:
> If DI is the really slow part of the framework, I think the DI specification
> generator is needed and fast. I can see from the benchmarks that DI takes
> around 20% of the time to generate. That means we can cut the request time
> from 500ms to something like 350 or 400. And it will also better reflect the
> real framework speed.

Not sure which benchmarks you're looking at, but by my calculations DI
accounts for more like 70-75% of the runtime on a basic hello world
page (index of the skeleton), not 20%.

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

xoops
DI has to be improved for performance consideration. 
I had the concern 20 days ago after looking at the code. https://twitter.com/#!/TaiwenJiang/status/167794580132085760


On Tue, Feb 28, 2012 at 1:18 AM, Evan Coury <[hidden email]> wrote:
On Mon, Feb 27, 2012 at 10:10 AM, Tomáš Fejfar <[hidden email]> wrote:
> If DI is the really slow part of the framework, I think the DI specification
> generator is needed and fast. I can see from the benchmarks that DI takes
> around 20% of the time to generate. That means we can cut the request time
> from 500ms to something like 350 or 400. And it will also better reflect the
> real framework speed.

Not sure which benchmarks you're looking at, but by my calculations DI
accounts for more like 70-75% of the runtime on a basic hello world
page (index of the skeleton), not 20%.

--
Evan Coury



--

Taiwen Jiang (aka D.J.)

Build Xoops Engine
web and mobile application platform

CTO for EEFOCUS.com
Leading social platform for electronics professionals


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

EvanDotPro
On Mon, Feb 27, 2012 at 6:00 PM, D. J. <[hidden email]> wrote:
> DI has to be improved for performance consideration.
> I had the concern 20 days ago after looking at the
> code. https://twitter.com/#!/TaiwenJiang/status/167794580132085760

Yes, and this has been known for many months (pretty much since day 1
with DI). Please see my previous posts in this thread regarding
compiled definitions.

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

weierophinney
Administrator
In reply to this post by xoops
-- D. J. <[hidden email]> wrote
(on Tuesday, 28 February 2012, 09:00 AM +0800):
> DI has to be improved for performance consideration.

Um, that's what everybody in this thread is saying...

Let me summarize and clarify

 * We're aware that DI is the current performance bottleneck.

 * Evan has shown that you can, with no changes to the framework itself,
   drop in a custom service locator in order to optimize performance.
   This demonstrates both that (a) DI is the performance bottleneck, and
   (b) the framework is de-coupled to a point that we can optimize by
   providing replacements when desired.

 * We have not prioritized DI performance in favor of getting the
   various framework features in place. Evan's demonstration validates
   this approach -- our attention to the architecture has made
   performance optimizations of this magnitude trivial.

When will we prioritize DI performance? After Ralph gets the initial DB
layer in place, it's his next priority. That means within the next 6-8
weeks, we will have a solution for this within a beta release.

> I had the concern 20 days ago after looking at the code. https://twitter.com/#!
> /TaiwenJiang/status/167794580132085760
>
>
> On Tue, Feb 28, 2012 at 1:18 AM, Evan Coury <[hidden email]> wrote:
>
>     On Mon, Feb 27, 2012 at 10:10 AM, Tomáš Fejfar <[hidden email]>
>     wrote:
>     > If DI is the really slow part of the framework, I think the DI
>     specification
>     > generator is needed and fast. I can see from the benchmarks that DI takes
>     > around 20% of the time to generate. That means we can cut the request
>     time
>     > from 500ms to something like 350 or 400. And it will also better reflect
>     the
>     > real framework speed.
>
>     Not sure which benchmarks you're looking at, but by my calculations DI
>     accounts for more like 70-75% of the runtime on a basic hello world
>     page (index of the skeleton), not 20%.
>
>     --
>     Evan Coury
>
>
>
>
> --
>
> Taiwen Jiang (aka D.J.)
>
> Build Xoops Engine
> http://www.xoopsengine.org
> web and mobile application platform
>
> CTO for EEFOCUS.com
> Leading social platform for electronics professionals
>
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Gregory
Hi Matthew,

On Mon, Feb 27, 2012 at 8:50 PM, Matthew Weier O'Phinney
<[hidden email]> wrote:
>  * Evan has shown that you can, with no changes to the framework itself,
>   drop in a custom service locator in order to optimize performance.
>   This demonstrates both that (a) DI is the performance bottleneck, and
>   (b) the framework is de-coupled to a point that we can optimize by
>   providing replacements when desired.


Can you clarify this a little more please, as currently, and I maybe
mistaken, it seems the only way to replace the DI object would be to
create a userland extension of the bootstrap class and override the
setupLocator method - there are no checks to see if one already
exists, or you would have to circumvent the main bootstrap method
altogether?

I was previously thinking that at some point the runtime definitions
would then be compiled/cached? Otherwise, and maybe incorrectly
thinking, how are independently compiled definitions going to handle
inter dependencies? Is there an RFC outlining this?

At one point I was thinking that runtime definitions could come in any
form, e.g xml/array, and a concrete locator class be generated or
updated (or indeed just specified or extended)?


--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

weierophinney
Administrator
-- Greg <[hidden email]> wrote
(on Tuesday, 28 February 2012, 12:58 AM -0600):

> On Mon, Feb 27, 2012 at 8:50 PM, Matthew Weier O'Phinney
> <[hidden email]> wrote:
> >  * Evan has shown that you can, with no changes to the framework itself,
> >   drop in a custom service locator in order to optimize performance.
> >   This demonstrates both that (a) DI is the performance bottleneck, and
> >   (b) the framework is de-coupled to a point that we can optimize by
> >   providing replacements when desired.
>
>
> Can you clarify this a little more please, as currently, and I maybe
> mistaken, it seems the only way to replace the DI object would be to
> create a userland extension of the bootstrap class and override the
> setupLocator method - there are no checks to see if one already
> exists, or you would have to circumvent the main bootstrap method
> altogether?

You would extend Zend\Mvc\Bootstrap, and override the setupLocator()
method. Since the Bootstrap is initialized in your index.php, this is an
easy, drop-in change.

> I was previously thinking that at some point the runtime definitions
> would then be compiled/cached? Otherwise, and maybe incorrectly
> thinking, how are independently compiled definitions going to handle
> inter dependencies? Is there an RFC outlining this?

Runtime definitions use Reflection. You can, at any point, take the
locator and dump the current definitions to an ArrayDefinition if
desired; however, the problem with doing so from the RuntimeDefinition
is that you will only know about the specific objects that are either in
configuration or which have been specifically retrieved; typically, this
will mean a subset of your application's classes for any given request.

The Di component also contains a class for compiling definitions by
performing static analysis of a codebase. The problem at this time is
that we have not yet written a CLI tool for consuming this class to
generate ArrayDefinition objects.

The other aspect, which you hint at in your second question above is how
to specify a list of compiled definitions for the DIC to consume; this
will be relatively trivial to write, however -- but is dependent on
having compiled definitions, and a way to easily compile them. Again,
the core code is available, we just need to write these pieces.

> At one point I was thinking that runtime definitions could come in any
> form, e.g xml/array, and a concrete locator class be generated or
> updated (or indeed just specified or extended)?

You're confusing RuntimeDefinitions with configuration here; the
configuration you use to seed the DI container can definitely come in
any form Zend\Config supports, and can contain configuration for
definitions -- though that definition configuration will only be used to
augment/enhance definitions provided by the RuntimeDefinition or
compiled definitions.

As for generating a service locator class, the support for this has not
been kept up-to-date with the DI API, and needs some work. However, this
is also another route we can definitely take towards creating a more
performant solution.

Again, the points are: the infrastructure is in place; we simply need to
do a little work in order to provide tooling to enhance performance.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Gregory
On Tue, Feb 28, 2012 at 9:53 AM, Matthew Weier O'Phinney
<[hidden email]> wrote:
> You would extend Zend\Mvc\Bootstrap, and override the setupLocator()
> method. Since the Bootstrap is initialized in your index.php, this is an
> easy, drop-in change.

I thought drop-in just meant placing a file somewhere and maybe just
changing a configuration setting etc. But I suppose its meaning can
vary.

Something that I haven't quite thought through, is whether or not it
would be possible (or feasible) for the EventManager to pull listeners
straight from the Locator if they exist for a particular event. The
thinking behind that is to minimize the work (etc) required to
register listeners for events - especially those that might not happen
frequently? But that was just a quick thought...


--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

weierophinney
Administrator
-- Greg <[hidden email]> wrote
(on Tuesday, 28 February 2012, 10:44 AM -0600):
> On Tue, Feb 28, 2012 at 9:53 AM, Matthew Weier O'Phinney
> <[hidden email]> wrote:
> > You would extend Zend\Mvc\Bootstrap, and override the setupLocator()
> > method. Since the Bootstrap is initialized in your index.php, this is an
> > easy, drop-in change.
>
> I thought drop-in just meant placing a file somewhere and maybe just
> changing a configuration setting etc. But I suppose its meaning can
> vary.

That's basically what the above proposes. I use "drop-in" here, vs.
"monkey patching" (i.e. altering ZF library code within your project),
which was the only way in ZF1 to accomplish similar performance
improvements. Basically, we can use extension (or implement an
interface) in order to introduce a substitution, without needing to
alter the framework or application lifecycle.

> Something that I haven't quite thought through, is whether or not it
> would be possible (or feasible) for the EventManager to pull listeners
> straight from the Locator if they exist for a particular event. The
> thinking behind that is to minimize the work (etc) required to
> register listeners for events - especially those that might not happen
> frequently? But that was just a quick thought...

This is something I'm interested in as well, and trying to find a
solution for. In most cases, registering the listeners is not much in
terms of performance overhead, but it would be nice to be able to reduce
boilerplate code in our modules as much as possible.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Sascha-Oliver Prolic
Well I think we can realize very lightweight listeners already now.
As an example I show a lightweight AclListener (it uses
Humus\Di\Locator, as a replacement for Zend\Di\Locator, just because
it uses already compiled definitions, but no difference in the api):

https://gist.github.com/1940408

It just hangs around doing nothing at all, consuming nearly no memory,
but as soon as an event comes up, that needs to be checked against
acl, it pulls the user and acl object and does the check. there can be
no acl instantiated at all, it will be build from di and given back as
soon as needed. if no acl checks are present in the request, no acl
object will be instantiated at all.

Regards

Sascha-Oliver Prolic

2012/2/28 Matthew Weier O'Phinney <[hidden email]>:

> -- Greg <[hidden email]> wrote
> (on Tuesday, 28 February 2012, 10:44 AM -0600):
>> On Tue, Feb 28, 2012 at 9:53 AM, Matthew Weier O'Phinney
>> <[hidden email]> wrote:
>> > You would extend Zend\Mvc\Bootstrap, and override the setupLocator()
>> > method. Since the Bootstrap is initialized in your index.php, this is an
>> > easy, drop-in change.
>>
>> I thought drop-in just meant placing a file somewhere and maybe just
>> changing a configuration setting etc. But I suppose its meaning can
>> vary.
>
> That's basically what the above proposes. I use "drop-in" here, vs.
> "monkey patching" (i.e. altering ZF library code within your project),
> which was the only way in ZF1 to accomplish similar performance
> improvements. Basically, we can use extension (or implement an
> interface) in order to introduce a substitution, without needing to
> alter the framework or application lifecycle.
>
>> Something that I haven't quite thought through, is whether or not it
>> would be possible (or feasible) for the EventManager to pull listeners
>> straight from the Locator if they exist for a particular event. The
>> thinking behind that is to minimize the work (etc) required to
>> register listeners for events - especially those that might not happen
>> frequently? But that was just a quick thought...
>
> This is something I'm interested in as well, and trying to find a
> solution for. In most cases, registering the listeners is not much in
> terms of performance overhead, but it would be nice to be able to reduce
> boilerplate code in our modules as much as possible.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc



--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Gregory
Hi Sascha,

On Wed, Feb 29, 2012 at 6:18 AM, Sascha-Oliver Prolic
<[hidden email]> wrote:
> https://gist.github.com/1940408

In that example, others might suggest that the acl object should be
injected rather than the locator object - meaning that if it was, that
could be a little more expensive, although more correct. Also,
explicitly specifying the User class string name for the
StaticEventManager suggests (in this case) that it would require more
work if the User class was replaced later on.

This is probably a topic for another thread though. For example, when
I previously tried to not use the StaticEventManager, but a single
instance as the global event manager, the event names collided. Which
made me wonder, regardless, whether the event names should be prefixed
with the component name (or be slightly more unique), for example
controller.dispatch, which might also make searching for specific
events a little easier.



--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Sascha-Oliver Prolic
Hi Greg,

thanks for your input. One thing I like to mention: There is no
hardcoded user class name. It uses the string "CurrentUser" which is
an DI alias for whatever. Only thing that needs to be sure, is that
the object, returned by "get('CurrentUser')" must implement the
Zend_Acl_Role_Interface. No concrete class is requested.
Next: I understand that injecting the acl and acl role (in this case
my current user) might be the cleaner solution, but remember that php
is not java. we don't have the services im memory waiting for
requests, instead we rebuild the whole application for every request,
so it is much much faster, if the acl is only loaded when needed. a
lot of request just serve content without needing an acl check. I
implemented a few listeners like that, all hanging around needing
nearly zero resources, and only when an interesting event was
triggerd, the objects will be pulled from di. even if pulling
resources from di, instead of injecting them, seems like an
antipattern in java, it is the only logical way to do in php.

Regards

Sascha-Oliver Prolic

2012/3/1 Greg <[hidden email]>:

> Hi Sascha,
>
> On Wed, Feb 29, 2012 at 6:18 AM, Sascha-Oliver Prolic
> <[hidden email]> wrote:
>> https://gist.github.com/1940408
>
> In that example, others might suggest that the acl object should be
> injected rather than the locator object - meaning that if it was, that
> could be a little more expensive, although more correct. Also,
> explicitly specifying the User class string name for the
> StaticEventManager suggests (in this case) that it would require more
> work if the User class was replaced later on.
>
> This is probably a topic for another thread though. For example, when
> I previously tried to not use the StaticEventManager, but a single
> instance as the global event manager, the event names collided. Which
> made me wonder, regardless, whether the event names should be prefixed
> with the component name (or be slightly more unique), for example
> controller.dispatch, which might also make searching for specific
> events a little easier.
>
>
>
> --
> Greg



--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Gregory
Hi Sascha,

On Thu, Mar 1, 2012 at 8:00 AM, Sascha-Oliver Prolic
<[hidden email]> wrote:
> thanks for your input. One thing I like to mention: There is no
> hardcoded user class name. It uses the string "CurrentUser" which is
> an DI alias for whatever.


The example has

$listener = new \Application\Event\AclListener(array(
    'Application\Service\User' => array(

Ok, so its not the User class, but User Service class... Basically I'm
thinking that here the class name of the scope being hard coded, but
the ZF code may of changed or I'm incorrect.

I'm not entirely against contextual lookups either :)


--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Sascha-Oliver Prolic
Hi Greg,

die Listener Configuration comes from di, too ;-)
The usage example is a liitle bit simplified to demonstrate the usage
of the class, not the usage in a real world app.

In my app listeners will be instantiated during bootstrap:

        $options = array(
            'Application\Event\CacheListener',
            'Application\Event\AclListener',
            'Application\Event\LogListener',
            // some more listeners
        );
        foreach ($options as $eventListenerClass) {
            $eventListener = $this->locator->get($eventListenerClass);
            $eventListener->attach();
        }

I have no hardcoded dependency on any concrete class (except i expect
a specific type to be returned from di, but even there not specific
class, i only expect some interface).

Regards

Sascha-Oliver Prolic

2012/3/1 Greg <[hidden email]>:

> Hi Sascha,
>
> On Thu, Mar 1, 2012 at 8:00 AM, Sascha-Oliver Prolic
> <[hidden email]> wrote:
>> thanks for your input. One thing I like to mention: There is no
>> hardcoded user class name. It uses the string "CurrentUser" which is
>> an DI alias for whatever.
>
>
> The example has
>
> $listener = new \Application\Event\AclListener(array(
>    'Application\Service\User' => array(
>
> Ok, so its not the User class, but User Service class... Basically I'm
> thinking that here the class name of the scope being hard coded, but
> the ZF code may of changed or I'm incorrect.
>
> I'm not entirely against contextual lookups either :)
>
>
> --
> Greg



--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

weierophinney
Administrator
In reply to this post by Gregory
-- Greg <[hidden email]> wrote
(on Thursday, 01 March 2012, 01:40 AM -0600):

> On Wed, Feb 29, 2012 at 6:18 AM, Sascha-Oliver Prolic
> <[hidden email]> wrote:
> > https://gist.github.com/1940408
>
> In that example, others might suggest that the acl object should be
> injected rather than the locator object - meaning that if it was, that
> could be a little more expensive, although more correct. Also,
> explicitly specifying the User class string name for the
> StaticEventManager suggests (in this case) that it would require more
> work if the User class was replaced later on.

I usually specify interface names when using the StaticEventManager, as
it makes it possible to inject replacements. The typical boilerplate for
lazy-loading the EventManager will (or should) include identifiers for:

    __CLASS__ (base class)
    get_called_class (class actually called)
    $listOfInterfacesImplemented

> This is probably a topic for another thread though. For example, when
> I previously tried to not use the StaticEventManager, but a single
> instance as the global event manager, the event names collided. Which
> made me wonder, regardless, whether the event names should be prefixed
> with the component name (or be slightly more unique), for example
> controller.dispatch, which might also make searching for specific
> events a little easier.

That's the problem with having the same EventManager instance across all
classes; you'll run into collisions like this. Ideally, you'd have
separate EM instances on each class, but inject a shared "global" or
"static" instance across each (instead of statically retrieving it);
this is the approach I want to hammer down for beta4.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
12