dmcgowan commented 8 years ago

The inmemory pipe implementation may simply use go channels instead of using a pipe.

Closes #92 Alternate implementation to #100

dmcgowan commented 8 years ago

@choleraehyq have a look at this as well. Sorry I really should have put this in a PR sooner instead of let it sit for months. This does add a buffered pipe as well which is kind of a new concept in libchan but I think it could be powerful since they are just as capable of being sent over the wire.

choleraehyq commented 8 years ago

@dmcgowan

100 has the same API as before, so it may have a better compatibility. Except for that, I think your version is more elegant.

dmcgowan commented 8 years ago

@choleraehyq this does not change any of the exposed API except to add a BufferedPipe.

dmcgowan commented 8 years ago

This change significantly reduces the overhead of sending local messages.

Benchmark comparison with this change...

libchan benchmark

benchmark              old ns/op     new ns/op     delta
BenchmarkRoundTrip     1719          682           -60.33%

spdy benchmarks

benchmark                      old ns/op     new ns/op     delta
BenchmarkSimpleCopy            21877         21169         -3.24%
BenchmarkSimpleLocalProxy      23651         22305         -5.69%
BenchmarkSimpleSpdyProxy       33408         33148         -0.78%
BenchmarkSimpleNoProxy         13986         10595         -24.25%
BenchmarkSimpleLocalPipe       4549          406           -91.07%
BenchmarkComplexCopy           1543162       555874        -63.98%
BenchmarkComplexLocalProxy     540662        477311        -11.72%
BenchmarkComplexSpdyProxy      907362        720482        -20.60%
BenchmarkComplexNoProxy        233039        228967        -1.75%
BenchmarkComplexLocalPipe      1624          709           -56.34%

docker / libchan

Update inmem pipe to use go channel #102

100 has the same API as before, so it may have a better compatibility. Except for that, I think your version is more elegant.