Feat/pull mplex

[dryajov]

UPDATE: This is now ready for review.

TODO:

• Performance
  • pool channel objects (should come next, but not critical for first release)

Bellow are the accompanying PRs:

• [WIP] feat: initial implementation of pull-streams based multiplexer js-libp2p-mplex#76
• fix deps js-libp2p-switch#254
• [WIP] feat: use pull stream based mplex js-libp2p#192
• [WIP] feat: use pull stream based mplex ipfs/js-ipfs#1346

---

The current implementation takes around ~15mins more running the mega stress tests defined in interface-stream-muxer.

Here is the outline:

New:

Old:

---

The issue is here - https://github.com/libp2p/pull-mplex/blob/850bbc52c33038f2cdeff40e83afbcf4823b3895/src/coder.js#L85...L89. I need to rework this part to use a preallocated buffer, instead of allocating it every time.

[daviddias]

@dryajov make this a PR to libp2p-mplex, not a new module.

[dryajov]

This module is implemented standalone so it can be consumed outside of libp2p, libp2p-mplex has been modified accordingly to consume it. The main idea is that this can be consumed by other projects.

[dryajov]

BTW, the same approach was taken with the go implementation - https://github.com/libp2p/go-mplex

[dryajov]

I was able to shave off ~15 mins of the new implementations running the mega stress tests, the perf is now about the same (or a little better ;) ) than the stream based implementation.

Archive.zip

The attached zip contains a heap snapshot and a perf log taken with node --prof --nologfile_per_isolate --logfile=xxxxxx.log --log-timer-events /private/var/folders/_r/6c6jf6m10kb3v9kt45qspw4w0000gn/T/v8profilerProxy.js. The one thing that still irks me a bit is the excessive (compared to the prev implementation) GC time. I think we can improve that a lot by pooling the Channel objects and reusing them, rather than creating new ones every time.

Here is a screenshot from the perf log graph - GC is seems to take ~13% of the total time. (These graphs where generated using the attached logs, and webstorm perf and heap analyzers).

[dryajov]

I'd love to get some feedback from @Stebalien as well.

[dryajov]

This PR got horked badly, please use #2 for further dev/reviews.