interface ISimpleSlot
{
    function callMe(): void;
}
class SimpleSlot implements ISimpleSlot
{
    public function callMe(): void{}
}

I wrote this simple test:

const REPS:int = 10000000;
var i:int;
var beforeTime:int;
var afterTime:int;
var slot:ISimpleSlot = new SimpleSlot();
var callbackName:String = "callMe";
 
beforeTime = getTimer();
for (i = 0; i < REPS; ++i)
{
    slot.callMe();
}
afterTime = getTimer();
log("direct call: " + (afterTime-beforeTime));
 
beforeTime = getTimer();
for (i = 0; i < REPS; ++i)
{
    slot[callbackName]();
}
afterTime = getTimer();
log("call through function name (no cast): " + (afterTime-beforeTime));
 
beforeTime = getTimer();
for (i = 0; i < REPS; ++i)
{
    (slot[callbackName] as Function)();
}
afterTime = getTimer();
log("call through function name (cast): " + (afterTime-beforeTime));

And got these results:

So it’s about 40x slower than a direct call. That’s a bit much of a compromise for TurboSignals. :)

What makes TurboSignals fast is the strong guarantee that the compiler and JIT are afforded by using a typed object: the Slot class. Removing the typing causes the slowdowns you see in both as3signals and EventDispatcher, although the latter has many more problems than just weak typing.

So the question is this: should we optimize for recursive dispatching (TurboSignals’ current way) or for thrown errors (the way the signal class you linked works)? To me the matter comes down to the legitimacy of the two uses cases. In my view, errors are bad but recursive dispatching is a valid feature of TurboSignals. I prefer not to punish the valid uses of TurboSignals for the sake of the invalid uses. You can, of course, do whatever you’d like to in your own signal class. :)

Code like that can delude a developer:

try { 
  signal.dispatch(wrongValue); 
} catch(e:Error) { 
  ...
  // now we think we have fixed everything but actually we have got a slow signal 
}

On the other hand this implementation will result in slower dispatching but do it clearly and in very rare situations (recursive dispatchings) http://github.com/whitered/Kote/blob/master/src/ru/whitered/kote/Signal.as

Not but what to wrap the slot call in a try/catch block is the worst idea as I think.

Personally I think that you should expect uncaught exceptions to do bad things to your program. TurboSignals is but a drop in the ocean of code that isn’t handling thrown errors. Luckily with TurboSignals you get off easy: the rest of your slots don’t get called and it performs slower from then on, but at least it never crashes.

I’d welcome anyone to reply here with comments on how TurboSignals should handle uncaught errors thrown by slots.