Very, very fast event library

Started by
53 comments, last by Iftah 16 years, 8 months ago
I think I'm finally running out of things to say... but it seems like ConnectionSet and AutoTracked could also use some swap functions.
Advertisement
ConnectionSet, sure. But the only use case I can think of for swapping AutoTrackeds which doesn't lead to undefined behavior is a bizarre murder-suicide pact. I suppose I could go deeper and allow the rebinding of connections inside a ConnectionSet to a new object, but that introduces some strange semantics. Frankly, the most reasonable solution I can think of is making AutoTracked noncopyable.
Now that I think about it more, I think thats the right approach. The thought of an AutoTracked object being passed by value as a function parameter gives me the heebie jeebies.
Mostly a matter of preference, but I would have implemented Connection::operator= something as follows:

Connection& operator=(Connection const& c){	Connection(c).swap(*this);	return *this;}

Arguing on the internet is like running in the Special Olympics: Even if you win, you're still retarded.[How To Ask Questions|STL Programmer's Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]
Now I am impressed by this. I've found boost::signals to be increasingly slow as my complexity level ramps up.

I don't know if there is something wrong with my compilation of boost signals, maybe I've not used the correct compiler settings when building it or something, but Sneftels VeryVeryFastEvent Library as I call it, is 322 times quicker!

322 times!

Hoooraaaah!

Thanks for a valuable contribution :)


Simon
Now, I do have one question.

At present your code seems to only offer Register, AutoRegister and Invoke Methods.

Any plans to add an Unregister method?

That would be very useful.

Thanks

Si
Neat. I've switched to a heavily event driven program flow in my games, and several months ago I wrote my own event/message passing system using FastDelegates which forms the backbone of my current game library. I didn't optimise it for speed however, and I've never been that comfortable with templates, so I'd doubt my version is as good as yours. I'll have a look at your implementation to see how you've solved the problem (and I'd be happy to post my code if you're interested, although it's probably a bit scrappy in places).
I had to do some hacking to get your example code to work in Xcode - I can never remember how to do proper timing code off the top of my head - but the bulk of your event class seems to run fine on Mac OS X. The exception is your swap function; Xcode does not like something about how the way you've declared the namespaces and/or friendship for the swap function to access the private declared AnyNodeType *mcode variable. I'm not enough of a C++ wizard for the reason for this to jump out at me, I'm afraid.

Still, with the swap code commented out everything else compiled fine. I plugged in my signal code to do the same speed test - your code runs in only 70% of the time (or conversely, mine is 1.4 times slower), so it is pretty darn speedy. I'll have to look at bit more in your internals to see what you're doing. I have noticed you seem to have a way to automatically cope with any number of arguments to your events. I had to hardcode different templates for each number of arguments I wanted to support (Signal0, Signal1<Arg1>, Signal2<Arg1, Arg2> etc.), and it's a real pain to keep them all in sync whenever I make code changes.
Given the reference counting nature of the listener list, it seems like the best way to do an unregister right now is to just to reset all of your connections.
Yeah, I'd got as far as using Clear() on the connectionSet.

A bit of a sledgehammer to crack a nut. :)

This topic is closed to new replies.

Advertisement