Is there an advantage to using a custom event sender vs the runtime sender

Question

Using esper or nesper I can issue events either from the runtime directly like so:

EPRuntime runtime = provider.getEPRuntime();
MyCustomEvent e = new MyCustomEvent("foo");
runtime.sendEvent(order);

or I can use a custom event sender like so:

EventSender sender = epService.EPRuntime.GetEventSender("MyCustomEvent");
MyCustomEvent e = new MyCustomEvent("foo");
sender.SendEvent(e);

I've tried to time this and it looks like the custom event sender might be faster, though it doesn't really seem to make a big performance difference from what I've seen.

Is there a compelling reason to chose one method over the other?

If I go with the second method of a custom EventSender, is it safe to cache the EventSender I get from the runtime so I don't have to query for it each time?

Answer 1

As always, the excellent esper documentation had the answer I was looking for:

From the docs they discuss the benefits of a typed EventSender like so:

This facility can reduce the overhead of event object reflection and type lookup as an event sender is always associated to a single concrete event type.

For events backed by a Java class (JavaBean events), the event sender ensures that the event object equals the underlying class, or implements or extends the underlying class for the given event type name.

So it looks like the answer is that using a custom event gives you type safety and possibly some performance gain due to the runtime not having to break out refection to determine what type of event is being pushed.