[Zope-PTK] New tool proposal: portal_events

[Andrew Wilcox]

At 10:44 AM 8/24/00 -0400, Ken Manheimer wrote:
>I haven't used an event notification system like this, but the idea of
>propagating an event object which manifests the event type and contains
>the event metadata appeals to me, too.  This would be much like
>class-based exceptions in python.  
>
>The primary concern which i don't know enough to answer is whether there
>would be performance problems, identifying event types by class
>isinstance().  Filtering on events is likely to be a common occurrence
>(um, event), while exceptions are, sorta by definition, uncommon (um,
>exceptional).
>
>I just don't know whether how frequency of isinstance() use scales up, and
>i bet this is one thing place where guessing isn't a good guide - if it
>really is attractive to go with class-based event objects, then the cost
>of doing lots of isinstances on a shallow class hierarchy might should be
>measured...

This is a common concern that OO and XP authors address: suppose I want to
use some design that (in my opinion) would make my code easier to read,
more maintainable, easier to change, etc. etc., but will it slow things down?

For example, a common object oriented refactoring is to replace a
calculation whose result is stored in a temporary variable with a query
method.  (See page 120 of Fowler's Refactoring).  Then every place that you
were referering to the temporary variable, you call the query method
instead.  Advantages include that any method in the class can now get to
the information, not just the original one that had the temporary variable;
your intention is clearer; it can make further refactorings possible such
as extracting and simplifying the original method.

But, now I'm calling the query method a bunch of times which is doing the
calculation, instead of doing the calculation just once and assigning it to
a temporary variable!  Obviously this is less efficient!!

But when people measure the performance of an application as a whole, what
they find is that it's only a small part of the code that's slowing it
down.  Optimizing the majority of the code *doesn't help the application
run faster*.

If your stategy is to optimize all of the code you write, and it's 5% of
the code that's the bottleneck, *95%* of your optimizing effort is *wasted*.

And, when it comes time to optimize the 5% that will actually do anything
to make the application run faster, often it is much *easier* to do that
optimization because your good design means that things are expressed in
one place.  Whether you can get a substantial improvement by using a new
algorithm or a respectable improvement by reimplementing the code using
different language features or perhaps in C, either way your good design
will help.

(Of course, whether or not my own proposal is a good design in this
particular situation is a different question!)

Andrew