[rust-dev] net::tcp::TcpSocket slow?

Patrick Walton pwalton at mozilla.com
Fri Dec 21 09:37:28 PST 2012

On 12/21/12 12:17 AM, Brian Anderson wrote:
> In the best case you essentially just want to be able to quickly
> transfer large buffers from the client task to the I/O task, or the
> other way. In a dual-core setup pipes should be able to do that very
> fast, rarely yielding to the (Rust) scheduler.

Well, my point is that in *this* benchmark we will still lose. The 
benchmark that Michael wrote waits on the results of each Redis query 
before sending the next one. This makes the main thread always fall 
asleep, so every pipe send will have to fall into the scheduler to punt 
the main thread awake. It's basically the worst case for our setup.

I suspect the performance of this benchmark would be better if:

(1) The code were written in a more asynchronous "fire-and-forget" style 
rather than waiting on the results of each query before sending the next 
one; and/or:

(2) There were large (like, 100,000+) numbers of tasks involved, so that 
the performance advantages of M:N threading over 1:1 threading start to 
kick in.

But, as written, this benchmark is fundamentally better served by 1:1 
blocking APIs.


More information about the Rust-dev mailing list