Because Tokio, while great for lots of things (ie default decent performance with ease of use), is a performance bottleneck if you want extremely high performance.

For example, the best this DB can do is ~3.7Mkeys/s for non durable writes and 162k/s for durable. I have an equivalent DB that’s always durable and does 30M/s* (for 8 byte entries) because it doesn’t use Tokio among other things. For this dataset it would be saturating the disk I/O no problem so I would expect it to be running ~7-14M/s depending on how fast your SSD is (~2-4x faster than non durable mode and 40-80x faster than its “durable”)

* it was running at 70-100mhz at one point but the challenge is keeping the hot path at ~10ns as you add features and other things.

▲

DarmokTanagra 15 hours ago | parent [-]

Thank you for a complete answer.

Out of curiosity where do you stand on libraries like this imposing a runtime choice on the user?

Is it standard in the rust ecosystem to have multiple async runtimes in a project?

	▲	vlovich123 14 hours ago \| parent [-]
		It’s fine to have multiple runtimes. There’s probably some additional performance overhead at the API boundary because you have to transfer the work to run on the other runtime but I haven’t benchmarked what that looks like. It’s probably on the order of 50ns-1us if done naiively and depending on contention (ie you’re looking at a max throughput of 20M-1M/s). Use whatever you want. Tokio is a very good work stealing runtime which is what Apple’s GCD popularized 17 years ago. It’s a fine model but sacrifices total throughput for ease of use and “easy” multithreading. Thread per core with pinned cores is what you use when you prioritize throughput and absolute possible latency. Tail latencies can suffer if you make a mistake and have imbalanced work on a single thread