You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
This has been on my TODO list ever since the switch to futures 0.3, and I had unfortunately totally forgotten about it.
While libp2p defaults to async-std because it "just works", tokio is presumably faster than async-std due to the fact that the reactor and executor are using the same threads.
This issue consists in briefly benchmarking the two and see if we see any difference in CPU usage.
I've applied this change on my Google Cloud node around 14:25UTC. I'll compare the CPU usage before and after in a couple of hours or tomorrow.
EDIT: to be clear, I purposefully didn't update the node in any way other than applying this diff, so that the measurement isn't influenced by anything else.
Note that I suspect that #5767 might be way more impactful.
Two hours and 100 connections later, it's not super convincing. Here is the CPU usage, you can't really see a difference (when the usage is on the lower end, ~1/3rd of this is normally the libp2p connections):
(the peak is when I restarted the node)
Here is the average time it took to poll a future dedicated to a libp2p node:
The moment when the curve almost reached 0 is when I restarted the node. If there is a difference between async-std and tokio, it seems to be lost in the background noise. It's very likely that our number of connections and traffic are not enough for a difference to actually matter.
I'll suspend this test unless we find a way to considerably reduce the background noise and have more precise measurements.
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.
Activity
tomaka commentedon Apr 24, 2020
The changes are quite small: https://github.com/paritytech/substrate/compare/master...tomaka:tokio-sockets?expand=1
I've applied this change on my Google Cloud node around 14:25UTC. I'll compare the CPU usage before and after in a couple of hours or tomorrow.
EDIT: to be clear, I purposefully didn't update the node in any way other than applying this diff, so that the measurement isn't influenced by anything else.
Note that I suspect that #5767 might be way more impactful.
tomaka commentedon Apr 24, 2020
Two hours and 100 connections later, it's not super convincing. Here is the CPU usage, you can't really see a difference (when the usage is on the lower end, ~1/3rd of this is normally the libp2p connections):
(the peak is when I restarted the node)
Here is the average time it took to poll a future dedicated to a libp2p node:
The moment when the curve almost reached 0 is when I restarted the node. If there is a difference between async-std and tokio, it seems to be lost in the background noise. It's very likely that our number of connections and traffic are not enough for a difference to actually matter.
I'll suspend this test unless we find a way to considerably reduce the background noise and have more precise measurements.
stale commentedon Jul 7, 2021
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.
tomaka commentedon Jul 8, 2021
Issue still important for historical context.
dmitry-markin commentedon Dec 7, 2022
Done in #12646.