> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
> Sent: den 17 december 2001 20:25
> To: Avalon Developers List
> Subject: Re: [Review] Event Queues
>
>
> Leo Sutic wrote:
>
> >
> That would be the way to minimize the cost of creating a Method object,
But this would maybe not have to be done more than once:
class MyStage extends AbstractStageWrapper {
public void handleConnectionOpen (ConnectionOpenEvent event) {
...
}
public void handleConnectionClosed (ConnectionClosedEvent event) {
...
}
}
class AbstractStageWrapper implements EventHandler {
private final HashMap handlerMethods = new HashMap ();
public void initialize () throws Exception {
// Iterate over own handler methods, and build a
// Class -> Method map.
}
public void handleEvent (QueueElement event) {
Method handlerMethod = (Method) handlerMethods.get (event.getClass ());
handlerMethod.invoke (...);
}
}
> and invoking it--done several hundred times a second, and now you are
> thrashing your Garbage Collection.
Like creating event methods 100 times a second?
> In many cases, the switch/case would not only be sufficient, but
> preferred.
I can only see it as preferred when the cost for invokation via
a Method instance is comparable to the cost for running the handler,
and I believe that to be the exception - the handler will always be
much more expensive than the invokation.
Looking above, can you fit the AbstractStageWrapper into the your Stage
interface design? I think it gives all the flexibility needed: Use
switch() if you want, use reflection if you want. Above all, it would
allow me to experiment. If reflection is too expensive then the idea can
die, and we can move on without having lost anything.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
