最近我用 Rust 写了一个 Redis client 的库，有兴趣看看吗？

那 pika 也可以用

js 和 go 界的事终于传播到了 rust 界？

@julyclyde 什么梗？

@ltoddy js 和 go 爱好者会把世界上早已存在的软件用自己的语言重新写一遍

我看了一下，我真觉得挺好，小还算美，洁癖我喜欢！用的是 std 的 sync io，性能应该，咳咳（老毛病...），有没有计划升级一下 io ？

@< href="/member/jinmingjian">jinmingjian 性能我用写了一个 benchmark，发现比异步要快很多……

我之前尝试过，多线程+CSP 处理方式，性能吊打异步。

@ltoddy 比 Rust 语言层的所谓 async 快，是很有可能的。现在 Rust 的 async 默认似乎是 thread local （不同版本可能有不同），对于大规模的 bench 肯定是不适合的，你需要调优。

但你现在这种同步式比真正高性能意义上的“异步”，那肯定是弱鸡的。

原因很简单，同步式调用在消息没返回之前线程时间片是浪费的，增加线程不改变这一点。这也和 CSP 无关，你 socket 读写是系统调用，任何用户态机制下，你这调用都必须浪费。CSP 和 coro/generator/future 本质是等价的，所以 CSP 并不会比 async 高明，且 Rust 不（完全）支持尾递归优化，写成 CSP 性能可能更弱。简单说，简单多线程效率比真正利用系统 /驱动层的异步机制效率至少差量级以上。我最近写 server，techmpower 的 plaintext 测试单机都是每秒一千万 request[1]，但 http 比 redis 说复杂 100 倍还是有的。

你可以把你的多线程+CSP 代码放出，我和你细品一下，当然时间是个问题，我们可以慢慢细品。

@jinmingjian 多线程+CSP 是我很早超不多一年前了吧，那时候测得。
我自己那个 redis-rs 项目里面，写了一个简单的 benchmark，可以使用 make bench 运行。
bench 里面代码是参照： https://github.com/mitsuhiko/redis-rs 他里面做的，因为我想和他比较一下。
（速度比他快。

我思考了一 i 个问题，虽然处理方式不一样，但是我感觉，一般来说整洁清晰，质量不错的代码，也往往性能不错。