EventEmitter: use a Map to store event listeners #1785

targos · 2015-05-24T15:12:26Z

This is a fix for #728.

I ran the events benchmarks to compare this with master and there seems to be a significant performance drop for some cases (though I'm not sure of how I should compare the runs).

Bench	master	Map
ee-add-remove	1216157	950515 (-22%)
ee-emit-multi-args	`5909434`	5640342 (-5%)
ee-emit	8485253	`7912000` (-7%)
ee-listener-count	432010872	56945905 (-87%)
ee-listeners-many	3558539	3490269 (-2%)
ee-listeners	21596479	18429471 (-15%)

petkaantonov · 2015-05-24T15:24:27Z

In the results you posted Map is always performing worse?

mscdex · 2015-05-24T15:26:19Z

lib/_stream_readable.js

  else
-    dest._events.error = [onerror, dest._events.error];
+    dest._events.set('error', [onerror, dest._events.get('error')]);


I believe all of these changes to readable stream are going to result in the same problem as when I proposed optimizations for eventEmitter.once() (#914), which is that some modules on npm have their readable-stream pinned to specific versions or limited version ranges. So if someone uses an older readable-stream on an io.js with these changes, things will break.

@mscdex That would be a lot of someones.

Last I checked npm (a few weeks ago) it was only about a dozen or so? I had actually thought about submitting PRs to those projects just so we could get the .once() optimizations.

Btw, there are other modules that are using _events directly. For example:

https://github.com/mscdex/dicer/blob/master/lib/Dicer.js#L91

https://github.com/mscdex/busboy/blob/master/lib/types/multipart.js#L183

https://github.com/unshiftio/ultron/blob/master/index.js#L79

That's in my current node_modules dir, except for the readable-stream.

@ChALkeR I was referring more generally about changes to readable-stream and how modules are depending on it version-wise, not specific code changes. But yes, there are probably a ton of modules that use _events directly.

Last I checked npm (a few weeks ago) it was only about a dozen or so?

Just in my current node_modules dir I have 19 of those. List:

bufferstreams "readable-stream": "^1.0.33" tar-stream "readable-stream": "~1.0.33", dicer "readable-stream": "1.1.x", duplexer2 "readable-stream": "~1.1.9" through2 "readable-stream": ">=1.0.33-1 <1.1.0-0", are-we-there-yet "readable-stream": "^1.1.13" decompress-zip "readable-stream": "^1.1.8", tar-pack "readable-stream": "~1.0.2", bl "readable-stream": "~1.0.26" readdirp "readable-stream": "~1.0.26-2" busboy "readable-stream": "1.1.x" raw-body "readable-stream": "~1.0.33", gulp-bower/through2 "readable-stream": ">=1.0.28 <1.1.0-0", htmlparser2 "readable-stream": "1.1" concat-stream "readable-stream": "~1.1.9", mongodb "readable-stream": "1.0.31" read-all-stream "readable-stream": "~1.1.13" finalhandler "readable-stream": "~1.0.33", duplexify "readable-stream": "^1.1.13"

If this gets merged, will 1.0.* and 1.1.* branches of readable-stream receive patches?
If yes, it is true that there are not so many packages that specify a fixed version of readable-stream as a dependency.

ChALkeR · 2015-05-24T15:28:11Z

@petkaantonov Map should be faster than an Object here. I guess that's the time measurements in that table. But it would be better if @targos shared his tests.

petkaantonov · 2015-05-24T15:28:57Z

The benchmark gives results in op/s (higher is better).

mscdex · 2015-05-24T15:30:01Z

lib/events.js

-          if (events.removeListener)
-            this.emit('removeListener', type, listener);
-        }
+        events.delete(type);


I'm curious about performance differences with this particular change. Is it faster to keep _eventsCount around and create a new Map()?

There is no significant performance difference if I revert ca75072. I tested with this._events.clear() and this._events = new Map()

ChALkeR · 2015-05-24T15:30:12Z

Ah, that's the bundled benchmark from io.js/benchmark/events, I missed that. Something is not right here then.

mscdex · 2015-05-24T15:32:28Z

src/node.cc

@@ -2914,9 +2914,6 @@ void SetupProcessObject(Environment* env,
  env->SetMethod(process, "_setupNextTick", SetupNextTick);
  env->SetMethod(process, "_setupPromises", SetupPromises);
  env->SetMethod(process, "_setupDomainUse", SetupDomainUse);
-
-  // pre-set _events object for faster emit checks
-  process->Set(env->events_string(), Object::New(env->isolate()));


Is this necessary? Isn't there a way to create a Map from C++?

Maybe. I couldn't find anything related to maps in the v8 API and I know that the Map constructor is written in JS but there may be a way to call it from C++

I see the NativeWeakMap but I can't find the regular Map either.

It will be possible with v8 4.5: v8/v8@395fa8b

targos · 2015-05-24T15:32:38Z

@petkaantonov is right, I assumed it was the time...
So yes, Map is always performing worse :(

yosuke-furukawa · 2015-05-24T16:22:55Z

ES6 Map is slower than Object props in V8.
Ref: https://code.google.com/p/v8/issues/detail?id=4014

And EventEmitter is our core module, if event emitter is slower, whole system may be slow on performance.

ChALkeR · 2015-05-24T17:32:15Z

@yosuke-furukawa This seems to depend on the usecase. I saw usecases where replacing objects with Maps resulted in a 2x speedup.

yosuke-furukawa · 2015-05-24T17:51:54Z

@ChALkeR Of course, the benchmark result is depend on the usecase. But current result seems to be worse. @petkaantonov is correct. our benchmark test shows ops per second https://github.com/nodejs/io.js/blob/master/benchmark/common.js#L225 .

ChALkeR · 2015-05-24T18:00:52Z

@yosuke-furukawa, Yes, I know about the bundled benchmarks.
In the original OP post there was a claim that these numbers show a performance speedup, that's why I thought that this is not a bundled benchmark but something of his own that measures the time taken.

Fishrock123 · 2015-05-24T18:12:43Z

Is prefixing events something that we can do without breaking anything? I think that would be a much better alternative. Map simply isn't fast enough yet.

targos · 2015-05-24T18:27:11Z

@yosuke-furukawa @Fishrock123 I agree that the current perf of Map is blocking this.
We can keep the PR open and re-run the benchmarks when there is a v8 upgrade to see if it's improving

chrisdickinson · 2015-05-25T00:09:07Z

It's going to be an uphill battle to directly change the format of _events, as @mscdex noted, at minimum making sure that both minor versions of readable-stream get a backwards-compatible patch release, and propagating that through the package ecosystem.

If the perf improves, I'd advise presenting a legacy _events interface via a getter and putting the map-backed interface behind a symbol or weakmap.

On May 24, 2015, at 11:12 AM, Jeremiah Senkpiel [email protected] wrote:

Is prefixing events something that we can do without breaking anything? I think that would be a much better alternative. Map simply isn't fast enough yet.

—
Reply to this email directly or view it on GitHub.

ChALkeR · 2015-05-25T12:17:58Z

Btw, about the _events usage — it looks like a very bad thing to me that modules use that.
It probably means that some of the API methods that should be there are missing.
Maybe the EventEmmiter api should be extended to cover those use-cases?

Samples:

readable-stream/lib/_stream_readable.js:
1. if (!dest._events || !dest._events.error)
2. else if (isArray(dest._events.error))
3. dest._events.error.unshift(onerror);
4. dest._events.error = [onerror, dest._events.error];
dicer/lib/Dicer.js
1. if (this._events.preamble)
2. if ((start + i) < end && this._events.trailer)
3. if (this._events[ev])
busboy/lib/types/multipart.js
1. if (!boy._events.file) {
ultron/index.js:
1. for (event in this.ee._events) { if (this.ee._events.hasOwnProperty(event)) {

It looks to me that there should be methods in EventEmitter to:

Get a list of all events from an EventEmmiter that currently have listeners.
(optional) Check if there are any listeners for a specific event. Like EventEmitter.listenerCount but using a prototype, like EventEmitter.prototype.listeners but returning just the count.
(optional) To prepend an event. Does the documentation specify the order in which the events are executed, btw?

~~Also it looks like readable-stream (ah, and iojs/lib/_stream_readable.js) breaks _eventsCount.~~ I was wrong, it's fine.

@mscdex, thoughts?

mscdex · 2015-05-25T14:05:31Z

@ChALkeR Using EventEmitter.listenerCount() is easy and efficient enough and was basically all I was using direct usage for.

ChALkeR · 2015-05-25T14:27:44Z

@mscdex That's why I marked that as (optional).
But ultron module iterates over events, and there seems to be no method for that in the public API.

mscdex · 2015-05-26T01:00:06Z

@ChALkeR Well, for that you could iterate over .listeners()?

chrisdickinson · 2015-05-26T01:36:14Z

readable-stream is directly vendored from core's streams. Core has a need for prepending events – userland does not (with the exception of readable-stream, which doesn't seem like a good excuse to add it.)
dicer seems to be checking for specific events, which would be better done with EE.listenerCount or even ee.listeners('event').
cloning an event emitter wholesale (like ultron is doing) is a pretty unexpected / surprising use of the EE API, I don't think we should support that.

sam-github · 2015-05-27T16:56:10Z

But ultron module iterates over events, and there seems to be no method for that in the public API.

Not to defend ultron - whatever it is - but introspecting an EE to see all the events that have been listened on would be very useful for debugging. For example, to check if a misspelled event name is being used. I'd like to see node be more introspectable, so if getting this info causes zero additional overhead, I think it'd be nice to have.

Qard · 2015-05-27T19:42:43Z

👍 to allowing more introspection of event emitters.

jasnell · 2015-08-27T01:54:49Z

@ChALkeR @targos ... No rush, just curious... where are things at on this one?

thefourtheye · 2015-08-27T03:34:04Z

lib/internal/symbols.js

@@ -0,0 +1,3 @@
+'use strict';
+
+exports.EE_events = Symbol('events');


Use camelCase.

targos · 2015-08-27T18:03:44Z

@jasnell I rebased on master. here are the new benchmark numbers:

Bench	master	Map
ee-add-remove	1100610	693568 (-37%)
ee-emit-multi-args	5566010	`5303709` (-5%)
ee-emit	8074416	7592220 (-6%)
ee-listener-count	409444871	44700710 (-90%)
ee-listeners-many	3426115	3345520 (-2%)
ee-listeners	21558724	15990929 (-26%)

targos · 2015-08-27T18:05:04Z

I guess I can close this PR for now. I don't think it will improve in a near future.

thefourtheye · 2015-08-27T18:08:38Z

@targos This also fixes another bug in the implementation. As of now, if we use inherited members as event names, it will confuse the events module a little. So I kinda hoped that this would land :(

jasnell · 2015-10-22T02:47:59Z

@targos ... Given the current status on this and your last comment, I'm inclined to close. Per @thefourtheye's comment tho, there may still be some stuff worth saving in this so perhaps another look is warranted? Particularly with the newer V8 in master?

targos · 2015-10-22T08:27:24Z

OK, closing for now.

@thefourtheye I think the problem you are talking about can be fixed by using Object.create(null) instead of an empty literal to create the map.

thefourtheye · 2015-10-22T08:39:08Z

@targos I tried that already in #2350 but looks like Object.create(null) is not preferred because of the performance hit.

targos · 2015-10-22T08:41:35Z

the performance tests were run in 2012. I would try with current V8 version to be sure it is still a problem.

thefourtheye · 2015-11-15T04:47:20Z

@targos I wrote this simple script to compare the performance of them

'use strict';

const times = 10e7;

console.time('Object.create');
for (var i = 0; i < times; i += 1) {
  let obj = Object.create(null);
}
console.timeEnd('Object.create');


console.time('Object Literal');
for (var i = 0; i < times; i += 1) {
  let obj = {};
}
console.timeEnd('Object Literal');

Object.create is 10 times faster, but the speed gain is in nano-seconds.

mscdex reviewed May 24, 2015
View reviewed changes

mscdex added the events Issues and PRs related to the events subsystem / EventEmitter. label May 24, 2015

targos force-pushed the fix-728 branch 2 times, most recently from 0921fb9 to 66518a0 Compare May 27, 2015 08:39

Fishrock123 added the future label May 27, 2015

ChALkeR mentioned this pull request May 27, 2015

EventEmitter API #1817

Closed

3 tasks

bnoordhuis force-pushed the master branch from 311c3e4 to b926718 Compare June 2, 2015 17:25

rvagg force-pushed the master branch from 9d21135 to 628a3ab Compare June 25, 2015 09:18

indutny force-pushed the master branch from bffb204 to eb35968 Compare July 22, 2015 21:21

vkurchatkin mentioned this pull request Aug 11, 2015

events: handle inherited properties properly #2350

Closed

thefourtheye reviewed Aug 27, 2015
View reviewed changes

lib/internal/symbols.js

@@ -0,0 +1,3 @@

'use strict';

exports.EE_events = Symbol('events');

Copy link

Contributor

thefourtheye Aug 27, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use camelCase.

events: use a Map to store listeners

d84a953

targos force-pushed the fix-728 branch from 66518a0 to d84a953 Compare August 27, 2015 18:03

rvagg force-pushed the master branch from 11c25c2 to ba02bd0 Compare September 6, 2015 11:55

targos closed this Oct 22, 2015

targos deleted the fix-728 branch June 1, 2017 09:06

targos mentioned this pull request Nov 16, 2017

[WIP] events: use Map for events and limit copying #17074

Closed

4 tasks

		@@ -0,0 +1,3 @@
		'use strict';

		exports.EE_events = Symbol('events');

EventEmitter: use a Map to store event listeners #1785

EventEmitter: use a Map to store event listeners #1785

Conversation

targos commented May 24, 2015

petkaantonov commented May 24, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChALkeR commented May 24, 2015

petkaantonov commented May 24, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChALkeR commented May 24, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

targos commented May 24, 2015

yosuke-furukawa commented May 24, 2015

ChALkeR commented May 24, 2015

yosuke-furukawa commented May 24, 2015

ChALkeR commented May 24, 2015

Fishrock123 commented May 24, 2015

targos commented May 24, 2015

chrisdickinson commented May 25, 2015

ChALkeR commented May 25, 2015

mscdex commented May 25, 2015

ChALkeR commented May 25, 2015

mscdex commented May 26, 2015

chrisdickinson commented May 26, 2015

sam-github commented May 27, 2015

Qard commented May 27, 2015

jasnell commented Aug 27, 2015

Choose a reason for hiding this comment

targos commented Aug 27, 2015

targos commented Aug 27, 2015

thefourtheye commented Aug 27, 2015

jasnell commented Oct 22, 2015

targos commented Oct 22, 2015

thefourtheye commented Oct 22, 2015

targos commented Oct 22, 2015

thefourtheye commented Nov 15, 2015