performance

[Tyler Wright]

I'm trying to figure out the performance benefits of what Joa has been working on with Signals. I haven't yet had time to set up tests, but am trying to reason with the code under the hood.

It looks like, for every listener that gets added there are two objects created (not pulled from an object pool or anything):

in Joa's master branch, Signal::registerListener.

188: bindings = new SignalBindingList(new SignalBinding(listener, once, this), bindings);

Robert's master creates a single Slot object. Though the dispatching linked-list iteration is faster in Joa's I wonder if it's worth the memory tradeoff.

That's the real question: do you think it's more important to save milliseconds and kilobytes on initialization or in the dispatching of the signal?

Tyler

[Stray]

Instinctively, creation should be significantly less frequent than dispatch - especially when coupled with lazy instantiation.

I don't know what the magic ratio is there - I have some signals that fire hundreds of times during my app and others that might only fire once, but dispatch seems like the more important optimisation to me.

I guess the saving really emerges when you have a signal with multiple handlers that is dispatching frequently... I don't have that scenario at the moment but if you were using a centralised EnterFrameSignal then you'd really be in that zone.

Stray

[Tyler Wright]

Thanks Stray!

I would guess the most common scenario in dispatching is in response to a use gesture - a mouse click or keyboard press triggering actions within the system. During that single thread of execution I wonder if there is enough signal-dispatching to make the dispatch performance relevant. Even if there are millions of dispatches over time the difference would only be made if they were happening in that same thread. At the least signals provides the chance to avoid the Event object in memory which does accumulate over time for garbage collection.

I suspect dispatching differences between an array iteration vs a linked-list would never be measurable outside of performance tests. So in the case of mobile optimization I think I'd go with less object instantiation for a smaller memory footprint.

Either way I love the consolidation of interfaces. I'd like to see the valueClasses:Array removed from the interface as well - they're useful in implementation but I don't think they get used via the ISignal API and I'd prefer not to have to support them in my own implementation.

thoughts?

Tyler

[Stray]

Cheers Tyler,

I'm definitely happy with the consolidation of interfaces - I'm just blogging on that very theme right now...

I have a feeling I used valueClasses in my Request-Response Signal utility, but only in the extending classes, so for my purposes it could be refactored from public to protected within the API.  I can't say I fully understand the purpose of it - I can see how it could be used defensively, but I'm wondering if there's a more powerful use that I just haven't considered. Maybe Robert can shine some light there.

Yes - I think the centralised Event.ENTER_FRAME replacement Signal is the only one where I can imagine many, many dispatches happening in the same thread. Possibly a top level mouse move signals for multiple items in a game - say lots of objects were doing collision detection or changing their motion based on one signal.

Perhaps there is a case for a SpeedySignal (crap name but you get the idea) that you'd use for those corner cases?

Certainly my experience matches what you're saying about there being few occasions where a signal is dispatched repeatedly in the same thread.

Stray 

[Xavier MARTIN]

Really interresting thread...
Stray what is your blog address please?

[Stray]

http://www.xxcoder.net - The post is just being proof read by a couple of people but will be up later this evening (it's called 'The Level-Up Cycle' and the part about interfaces and Signals interface issues is near the end.

Thanks for asking :)

[Tyler Wright]

Stray - are you really a sheep enthusiast?

I better make sure I'm careful what I say about sheep...

[Stray]

I really *am* a sheep enthusiast.

We have a couple of Welsh Badger-Faced Mountain Sheep, and in the village where I live there are 50 people and 2000 sheep.

I have aspergers, which is probably why when I moved to sheep-farming country the first thing I got interested in was learning to identify all the different breeds of sheep. I am ridiculous. (But easily pleased).

[Xavier MARTIN]

I'll  check the link thx...
As for myself I live in nz, so it's the same here: there is a lot of sheep per inhabitants ;)

[Joa Ebert]

Hi,

as3signals has always been a library that is easy to use and very robust. Robert did a great job focussing on the usability of his library. With the changes I made I tried to follow his idea. Of course it is not rocket science to create something that is faster than the as3signals library with something like Signal0, Signal1, ... SignalN classes that are hardcoded for instance.

However I think performance is simply good enough. In a observe-dispatch environment you usually focus on the dispatch phase. Altering the state of the Signal is a less common operation. You can read about this in Java Concurrency In Practice.

My implementation uses a persistent linked list. This list is very fast to traverse and has a small memory footprint. It allows you to have efficient temporary listeners as well (if added at the beginning of the list which is what I am doing). In the end the persistent list allowed me to delete a lot of code and make the whole library much simpler. 

You could optimize adding and removving listeners. I did this by using a Dictionary as well that I will probably remove again. If you need to add a million listeners, we should have something like a SignalBuilder and use that pattern for such corner cases. In fact a Dictionary creates an unnecessary memory footprint that makes adding/removing/contains checks faster.

Again I think you can optimize a lot more but it is not necessary -- you will probably increase the memory footprint for no reason. The signals code is very clean and dispatch is very fast. The most common operations are also very fast thanks to the SignalBinding class that allows you to alter a Signals state temporary (pause and resume for instance).

Best,

Joa

[Tyler Wright]

Thanks Joa! I've thoroughly enjoyed reviewing your approach to Signals.

Overall this has been a fun project to explore. I liked Robert's concepts from the beginning and hope to see it more widely utilized.

Tyler

[Stray]

Thanks Joa too :)

For my purposes, as3signals has always been more than good enough.

Thanks for taking the time to explain the tradeoffs you're considering - the kind of projects I work on are rarely speed/size critical, so I don't know enough about memory vs optimization (though your explanation made a lot of sense).

I think you're right that in the case of adding many, many listeners, a utility / builder class to facilitate this would be a solid approach.

Your point about Signal0 may not be a daft one. Perhaps EmptySignal is worth considering (unless there already is one?) - for something like a central ENTER_FRAME, where the Signal is under most pressure?  Just a thought - not a very formed one!

Stray

[Robert Penner]

I love this discussion. What I'll add is that with optimization, I
sometimes stop to ask:

When do you stop optimizing?
How fast is fast enough?
How much RAM is too much?

Optimization is fun but if it starts to restrict you, you'd better
know what your goal is, and measure your progress toward it.

Robert

[Tyler Wright]

I love this discussion. What I'll add is that with optimization, I
sometimes stop to ask:

When do you stop optimizing?
How fast is fast enough?
How much RAM is too much?

Optimization is fun but if it starts to restrict you, you'd better
know what your goal is, and measure your progress toward it.

Robert

It's easy to get carried away with the fun. The nice thing about signals is that it's already done and such a clean, simple project that optimization doesn't take any time. So all you have left are the fun examples and discussions around who did what approach and what they were able to achieve.

As far as how this discussion impacts the core project, I don't think Joa's, my or anyone else's implementation should change the current approach. However I'd like to know if there is serious consideration for making updates to the signal Interface. Even as I build my own Signal implementation I'd still like to have it rooted in the AS3-Signals project by virtue of the Interfaces. I'm happy to use what is available, but if there is real consideration for changing I'm happy to contribute where I can.

thanks Robert!

Tyler

[Robert Penner]

Yes, the interfaces can be changed. Start threads! Discuss!