Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Add AsyncIterable benchmarks #361

Merged
merged 6 commits into from
Aug 19, 2024
Merged

Conversation

dapplion
Copy link
Contributor

Benchmarks to understand the cost of extra iterations in AsyncIterable flows

Benchmark output in a 4 core, model name: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz

  abortableSource cost
    ✔ async iterate abortable x0 bytesSource 10000                        240.8675 ops/s    4.151660 ms/op        -        274 runs   1.64 s
    ✔ async iterate abortable x1 bytesSource 10000                        81.45703 ops/s    12.27641 ms/op        -        140 runs   2.22 s
    ✔ async iterate abortable x2 bytesSource 10000                        56.36310 ops/s    17.74210 ms/op        -        127 runs   2.77 s
    ✔ async iterate abortable x3 bytesSource 10000                        44.51953 ops/s    22.46205 ms/op        -         16 runs  0.876 s
    ✔ async iterate abortable x4 bytesSource 10000                        27.24913 ops/s    36.69842 ms/op        -         50 runs   2.35 s

  pipe extra iterables cost
    ✔ async iterate pipe x0 transforms 10000                              382.6632 ops/s    2.613264 ms/op        -        739 runs   2.44 s
    ✔ async iterate pipe x1 transforms 10000                              228.8201 ops/s    4.370245 ms/op        -         95 runs  0.917 s
    ✔ async iterate pipe x2 transforms 10000                              147.2555 ops/s    6.790917 ms/op        -        294 runs   2.50 s
    ✔ async iterate pipe x4 transforms 10000                              87.32153 ops/s    11.45193 ms/op        -         77 runs   1.39 s
    ✔ async iterate pipe x8 transforms 10000                              47.20064 ops/s    21.18615 ms/op        -         41 runs   1.38 s

wemeetagain
wemeetagain previously approved these changes Aug 9, 2024
Copy link
Member

@wemeetagain wemeetagain left a comment

Choose a reason for hiding this comment

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

merging this

achingbrain added a commit to libp2p/js-libp2p that referenced this pull request Aug 14, 2024
To allow doing things like having a single `AbortSignal` that can
be used as a timeout for incoming connection establishment, allow
passing it as an option to the `ConnectionEncrypter` `secureOutbound`
and `secureInbound` methods.

Previously we'd wrap the stream to be secured in an `AbortableSource`,
however this has some [serious performance implications](ChainSafe/js-libp2p-gossipsub#361)
and it's generally better to just use a signal to cancel an ongoing
operation instead of racing every chunk that comes out of the source.
achingbrain added a commit to libp2p/js-libp2p that referenced this pull request Aug 14, 2024
To allow doing things like having a single `AbortSignal` that can
be used as a timeout for incoming connection establishment, allow
passing it as an option to the `ConnectionEncrypter` `secureOutbound`
and `secureInbound` methods.

Previously we'd wrap the stream to be secured in an `AbortableSource`,
however this has some [serious performance implications](ChainSafe/js-libp2p-gossipsub#361)
and it's generally better to just use a signal to cancel an ongoing
operation instead of racing every chunk that comes out of the source.
achingbrain added a commit to ChainSafe/js-libp2p-noise that referenced this pull request Aug 14, 2024
To allow doing things like having a single `AbortSignal` that can be
used as a timeout for incoming connection establishment, allow passing
it as an option to the `ConnectionEncrypter` `secureOutbound` and
`secureInbound` methods.

Previously we'd wrap the stream to be secured in an `AbortableSource`,
however this has some [serious performance implications](ChainSafe/js-libp2p-gossipsub#361)
and it's generally better to just use a signal to cancel an ongoing
operation instead of racing every chunk that comes out of the source.
@wemeetagain wemeetagain merged commit 0ede9cd into master Aug 19, 2024
9 checks passed
@wemeetagain wemeetagain deleted the dapplion/benchmark-async branch August 19, 2024 16:50
achingbrain added a commit to ChainSafe/js-libp2p-noise that referenced this pull request Aug 29, 2024
To allow doing things like having a single `AbortSignal` that can be
used as a timeout for incoming connection establishment, allow passing
it as an option to the `ConnectionEncrypter` `secureOutbound` and
`secureInbound` methods.

Previously we'd wrap the stream to be secured in an `AbortableSource`,
however this has some [serious performance implications](ChainSafe/js-libp2p-gossipsub#361)
and it's generally better to just use a signal to cancel an ongoing
operation instead of racing every chunk that comes out of the source.
achingbrain added a commit to libp2p/js-libp2p that referenced this pull request Aug 30, 2024
To allow doing things like having a single `AbortSignal` that can be used as a timeout for incoming connection establishment, allow passing it as an option to the `ConnectionEncrypter` `secureOutbound` and `secureInbound` methods.

Previously we'd wrap the stream to be secured in an `AbortableSource`, however this has some [serious performance implications](ChainSafe/js-libp2p-gossipsub#361) and it's generally better to just use a signal to cancel an ongoing operation instead of racing every chunk that comes out of the source.

BREAKING CHANGE: the final argument to `secureOutbound` and `secureInbound` in the `ConnectionEncrypter` interface is now an options object

---------

Co-authored-by: chad <[email protected]>
achingbrain added a commit to libp2p/js-libp2p that referenced this pull request Sep 6, 2024
To allow doing things like having a single `AbortSignal` that can be used as a timeout for incoming connection establishment, allow passing it as an option to the `ConnectionEncrypter` `secureOutbound` and `secureInbound` methods.

Previously we'd wrap the stream to be secured in an `AbortableSource`, however this has some [serious performance implications](ChainSafe/js-libp2p-gossipsub#361) and it's generally better to just use a signal to cancel an ongoing operation instead of racing every chunk that comes out of the source.

BREAKING CHANGE: the final argument to `secureOutbound` and `secureInbound` in the `ConnectionEncrypter` interface is now an options object

---------

Co-authored-by: chad <[email protected]>
achingbrain added a commit to libp2p/js-libp2p that referenced this pull request Sep 6, 2024
To allow doing things like having a single `AbortSignal` that can be used as a timeout for incoming connection establishment, allow passing it as an option to the `ConnectionEncrypter` `secureOutbound` and `secureInbound` methods.

Previously we'd wrap the stream to be secured in an `AbortableSource`, however this has some [serious performance implications](ChainSafe/js-libp2p-gossipsub#361) and it's generally better to just use a signal to cancel an ongoing operation instead of racing every chunk that comes out of the source.

BREAKING CHANGE: the final argument to `secureOutbound` and `secureInbound` in the `ConnectionEncrypter` interface is now an options object

---------

Co-authored-by: chad <[email protected]>
achingbrain added a commit to libp2p/js-libp2p that referenced this pull request Sep 6, 2024
To allow doing things like having a single `AbortSignal` that can be used as a timeout for incoming connection establishment, allow passing it as an option to the `ConnectionEncrypter` `secureOutbound` and `secureInbound` methods.

Previously we'd wrap the stream to be secured in an `AbortableSource`, however this has some [serious performance implications](ChainSafe/js-libp2p-gossipsub#361) and it's generally better to just use a signal to cancel an ongoing operation instead of racing every chunk that comes out of the source.

BREAKING CHANGE: the final argument to `secureOutbound` and `secureInbound` in the `ConnectionEncrypter` interface is now an options object

---------

Co-authored-by: chad <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants