event-chain with cache

[snowyu]

Add the event cache to improve performance and reduce memory usage.

the new with event cache:
➜  event-emitter git:(feature/event-chain) node benchmark/many-on.js
Emit for 3 listeners x1000000:

1:   582 EventEmitter2
2:   602 EventEmitter (Node.js native)
3:   851 event-emitter (this implementation)
4:  3355 Signals
➜  event-emitter git:(feature/event-chain) node benchmark/single-on.js
Emit for single listener x1000000:

1:   105 EventEmitter2
2:   122 EventEmitter (Node.js native)
3:   244 event-emitter (this implementation)
4:  3010 Signals

the old implementation (no cache) can not be endured:

Emit for single listener x1000000:

1:    94 EventEmitter2
2:   146 EventEmitter (Node.js native)
3:  2901 Signals
4: 11828 event-emitter (this implementation)

[medikoo]

@snowyu I'm not sure what you mean. Results as you pasted first are coming from current version as published.

$ node -v
v0.10.36
$ node benchmark/many-on.js 
Emit for 3 listeners x1000000:

1:   341 EventEmitter (Node.js native)
2:   341 EventEmitter2
3:   481 event-emitter (this implementation)
4:  1893 Signals

$ node benchmark/single-on.js 
Emit for single listener x1000000:

1:    54 EventEmitter2
2:    64 EventEmitter (Node.js native)
3:   100 event-emitter (this implementation)
4:  1486 Signals

and again this implementation is event agnostic, adding any complexity may just slow it down

[snowyu]

the first is the same complexity feature with second but not slow it down!

[snowyu]

I would open a new project for this support if u do not like it.

[snowyu]

It is mainly used as hooked event for database to validate data before saving.

[medikoo]

@snowyu sorry at first I understood that you suggest that currently event-emitter returns second result.

Still, event listener must be called in scope of it's emitter, we can't just change it so it's something else. It's common pattern for all event emitter implementations and it's used heavily by programs. So just for this reason this change is not acceptable.

Event object is always passed as an argument, and it's how event-emitters are used in both native and user land API's, just see for example DOM API.

[snowyu]

Ok, it doesn't matter. In deed it is a broken change. personally, I always use the 'that' pattern(=>), so it do not affect me. I will dig a new pit. I am too lazy to maintain hook and event both.

[snowyu]

The new pit is almost done as event-ex package.

• rewrite the core architecture
• keep most compatible with node events and event-emitter
• more powerful event-able ability
• hookable event system
• Difference with node events
  • domain is not supported yet(TODO)
  • broken change: The event object bubbling Supports
  • the event object as listener's "this" object.
  • return the result property of event object to emitter.
  • prevent the rest of listener from be excuted if set the stopped property of event object to true
  • broken change: the emit return the result of listeners's callback function instead of the successful state.
  • broken change: the this object of listeners' callback function is the Event Object instead of the emitter object.
    • the emitter object is put into the target property of the Event Object.
• Difference with event-emitter
  • broken change: The event object bubbling Supports(see above)
  • add the defaultMaxListeners class property to keep compatible with node events.
  • add the setMaxListeners method to keep compatible with node events.
  • add error, newListener and removeListener events to keep compatible with node events.
  • add listeners() method to keep compatible with node events.
  • add listenerCount() class method to keep compatible with node events.

[medikoo]

:+1:

[snowyu]

Would you want to help maintaining the events-ex package together?