Updating the comparison with Tokio's new (2019-10-13) scheduler

[Qqwy]

Tokio is switching to a new scheduler implementation. Read "Making the Tokio Scheduler 10x faster" for the details.

As such, it would be nice if a new comparison/benchmark of between May and Tokio could take place, as it means that the 'Performance' section of the current README will become outdated.

[Xudong-Huang]

Great article! Sure, I will update the doc when new tokio settle down.

[zhuxiujia]

Tokio is switching to a new scheduler implementation. Read "Making the Tokio Scheduler 10x faster" for the details.

As such, it would be nice if a new comparison/benchmark of between May and Tokio could take place, as it means that the 'Performance' section of the current README will become outdated.

cant beat tokio。

fn main() {
    may::config().set_workers(6).set_stack_size(0x1);
    let total=1000000;
    for _ in 0..total{
        go!(move || {
           may::coroutine::sleep(Duration::from_secs(1*60*60));
        });
    }
    println!("done");
    std::thread::sleep(Duration::from_secs(1*60*60));
}

• this code consume 4.44GB Memory。
• in golang，that takes 2.35GB.
• in tokio, this code takes only 500MB（Maybe because of zero cost abstraction）.

so. i say cant beat tokio。 Maybe it's because of CSP mode. High concurrence in CSP is not high

[Xudong-Huang]

Yes, you are right, CSP consume more memory. I will update the bench data in a separate place, not in the README. For detailed io performance you can ref to https://tfb-status.techempower.com/

[Xudong-Huang]

now I place the latest simple comparison with latest tokio version under performance.md. I don't want to misleading people about real performance, people should have their own judge to select a proper tech for projects.

[zhuxiujia]

Yes, you are right, CSP consume more memory. I will update the bench data in a separate place, not in the README. For detailed io performance you can ref to https://tfb-status.techempower.com/

I still don't understand why memory resource consume is higher than golang。

may::config().set_workers(6).set_stack_size(0x1);

If memory consumption is too high, it is difficult to deal with the C10K problem。

on the other hand, Future has no stack, so it can adapt to memory growth. Unless may can automatically adjust the stack like go

[Xudong-Huang]

10K coroutine will consume at least 10_000 * 4K = 40M bytes memory. 1M coroutine need 4G bytes memory at least. May don't support growth stack automatically. It's very hard for a library to grow stack dynamically. Futures are stackless, that's why the rust team choose it.