Checked out TurboSignals by Jackson Dunstan today. Please stop sending me this link over and over again.

I see a lot of people don’t understand the point. “ZOMG IT’S ZILLION TIMES FASTER I MUST USE IT EVERYWHERE!!!!1″. No you don’t. Everything should be used where it fits. I saw a lot of people started using architectural frameworks like PureMVC or Swiz without understanding the theory behind them. Thus inventing hacks to overcome framework “constraints” while what they see as “constraints” come from their lack of knowledge.

A lot of people think that if something is advertised as being good and fast they must use it in their projects. STOP NOW! Think first if you really need all this stuff.

Same here. I am absolutely happy with Events and I love all sort of bubbling. Events are good for UIs and tree-like structures. I don’t have to reinvent the wheel. I just work with events everywhere in the same manner.

BUT! If I need greater performance somewhere in critical code chunks I’m using simple function calls. I know that I create obvious dependencies but I do it where it makes sense. You should not rush to change Events to Signals or whatever everywhere. Inventing hacks and making your app impossible to maintain.

Check out TurboSignals sources, there are like 20 lines of code which do stuff. You could implement such interface-based notifying yourself.

What you really should do is to read the whole Jackson’s blog. You’ll find a lot of information about AS3 optimization and stuff. Good job, man!

Continuing on as3-signals. Here the guy actually ran performance tests on as3-signals vs. events. And got surprisingly SHOCKING results. You won’t gonna believe — AS3-SIGNALS ARE FASTER THAN EVENTS!!!!!1 Who could have thought that, huh? OK, </sarcasm>. Just looking at the code you can tell that as3-signals being simpler will be faster. This is definitely good.

But, if you need 0(zero) or 1(one) listener for your object, use plain old callbacks and you will be shocked by performance boost!

I added this code to the guy’s test:

public var callback:Function;
public function dataCallback():void
{
for (var i:uint = 0; i < loops; i++)
this.callback(i);
}

And here are the results

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
1 (5 iterations)
Player version: MAC 10,0,42,34 (debug)
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
Events                                                     3107   621.40
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
1 (5 iterations)
Player version: MAC 10,0,42,34 (debug)
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
Signals                                                    2198   439.60
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
1 (5 iterations)
Player version: MAC 10,0,42,34 (debug)
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
Callback                                                    255    51.00
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Someone has too much time running tests and drawing graphs. Oh wait, it’s me. At least I haven’t drawn a graph.

P.S. Once again, as3-signals is good, opensource is good! cheers~

Lately there was a lot of attention in English-speaking Flash community to Robert Penner’s AS3 Signals library. I’m surprised because there’s nothing revolutionary and even new in this approach. Yes, this concept is good in special cases. And yes, I agree that Flash events are ugly.

First of all, if you don’t know what I am talking about take a moment to check the library on the web.

Second, read my previous post about silent developers and flash community.

Well, every flash developer earlier or later starts thinking about Flash events system. Events are in the core of ActionScript 3.0 but you might consider their implementation ugly. I’ll be referring to Robert’s post one and post two. Where he says that:

• addEventListener syntax is awkward

  public function addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void

  I agree that useCapture is only needed for DisplayObject events, but I disagree that useWeakReference should be widely used. This is bad practice adding stuff and hope that it will be somehow magically removed later. You must always unsubscribe manually.

• He doesn’t like Event class properties and methods related only to DisplayObject events. But is having 2 event systems better?
• There should be additional methods like addOnce() or removeAllListeners(). Every experienced developer has already written helpers for these actions. If not more.
• It is not possible to implement IEventDispatcher without using an EventDispatcher object. Yes, trying to extend Flash events model is hard. In fact I saw an implementation of event bubbling through a tree of special objects (which are not DisplayObjects) which mimics standard event bubbling behavior. The code is full of dirtiest hacks I’ve ever seen.

After, Robert proposes his own events model. I’m not saying that the idea is bad. No, it has its pluses and might be used in a couple of small projects. Flash developers are tied to using events by design. Signals and wrapping events just don’t magically solve problems. As I mentioned before, most of experienced Flash developers wrote their helpers and some of them even developed bubbling mechanisms for objects other than DisplayObject.

Flash events are too simple when used out of display list and has some unused code, that’s correct. But they shine if used within display list. Especially if you develop interfaces. Bubbling, capture phase, canceling and stopping events — these are very convenient tools. A lot of the times I find myself catching children events in some common “root” object, for example.

Yes, Signals are simple. But try adding bubbling, phases, canceling and stopping functionality to them and you’ll get plain old Events. Let’s check what else Robert says on the site.

• Removing unnecessary code feels great.
  You just remove one code adding another.
• Composition and interfaces are favored over inheritance. Events in interfaces are a good thing.
  I don’t see this as advantage, events are usually registered with [Event] metatag so Flex Builder can use autocomplete. From numerous public properties I have to find a Signal object I need.
• Event types are classes, not strings.
  OK, while you don’t have other properties Event class provides you are good. What will you do when you need target, currentTarget and others? Oh, I missed the DeluxeSignal class. Looks like you are going back to Event object. Event types are not only strings either in Flash events. Event type is a class extending Event class + event name.
• Event classes should focus on the data they contain, not on who sends them.
  Event class contains just enough information listeners need. Consider it an e-mail. What Signals dispatch looks more like huge boxes with different stuff. Do all your listeners need all that?
• Event classes should not contain string constants that various other classes use.
  Who said that?
• So far, not a single “static” keyword in the source.
  Static event names are not mandatory, they are used for compile time checking. Consider your own example:

  progress.dispatch('The Answer', 42); // will succeed

  If you pass some kind of a name here you’d create a static constant for it too. In case you mistype it.

I agree that releasing code is good, I agree that using Flash events out of display list might look like shooting flies with a turret, but I don’t understand why people are so excited. Once again,

1. Experienced Flash developers have created their own helper classes long time ago
2. Signals are good while they are simple
3. Some of pluses mentioned are questionable
4. I doubt we need 2 event mechanisms and wrappers between them

This is more like a toy.

And last, a lot of people use events wrong. That’s where stuff like data:Object properties in custom events come from.