I ran a quick benchmark and noticed a 5x performance difference between OpenDAL and standard tokio fs, is this to be expected or is it due to an issue on my end? I expected it to be similar and the syscalls themselves taking up most of the time. Total files : 1000 Throughput OpenDAL : 5582.291712217004 Duration OpenDAL : 1.791378974s Throughput Tokio : 23291.168105044584 Duration Tokio : 429.347294ms

I think the benchmark itself is unfair: - opendal calls

sync_call

after write to make sure the file is really presist on the fs, but

tokio::fs::write

didn't. - opendal's

delete

works for both file and dir (so users don't need to tell whether it's a dir or not). If we changed tokio to do the similiar things: create_dir_all + open/create/truncate + write_all + flush + sync_all + metadata we will get the similiar results (even faster):

OpenDAL duration: 48.20476275s, throughput: 207.45 files/s
Tokio duration  : 48.531082918s, throughput: 206.05 files/s
Tokio/OpenDAL throughput ratio: 0.99x

Okay, that makes sense. I was not aware that tokio file writes are not guaranteed to have written any data when the future completes (https://github.com/tokio-rs/tokio/issues/5531). Just out curiosity, could I see your test code? I'm interested in seeing which previously missing operations are the slowest and contribute most to the discrepancy.

replace

fs::write

with creating a tokio File and calling

write_all

and

sync_all

instead