4 ms·
Last time this was here, I ran this and got the following results: /fast-sqlite3-inserts (master)> time make busy-rust Sun Jul 18 17:04:59 U
by IfOnlyYouKnew 5y ago
Last time this was here, I ran this and got the following results:
/fast-sqlite3-inserts (master)> time make busy-rust
Sun Jul 18 17:04:59 UTC 2021 [RUST] busy.rs (100_000_000) iterations
real 0m9.816s
user 0m9.380s
sys 0m0.433s
________________________________________________________
Executed in 9.92 secs fish external
usr time 9.43 secs 0.20 millis 9.43 secs
sys time 0.47 secs 1.07 millis 0.47 secs
fast-sqlite3-inserts (master)> time make busy-rust-thread
Sun Jul 18 17:04:48 UTC 2021 [RUST] threaded_busy.rs (100_000_000) iterations
real 0m2.104s
user 0m13.640s
sys 0m0.724s
________________________________________________________
Executed in 2.33 secs fish external
usr time 13.68 secs 0.20 millis 13.68 secs
sys time 0.78 secs 1.18 millis 0.78 secs
I'm probably doing something wrong. Or I'm getting the pace needed for the billion?
This is on a M1 MacBook Air.
- tln 5y agohttps://github.com/avinassh/fast-sqlite3-inserts https://github.com/avinassh/fast-sqlite3-inserts
- mpweiher 5y ago> I'm probably doing something wrong. Yes, it turns out. :-) The "busy-*" programs just run the loops without doing any SQLite operations, in order to test loop overhead. On my M1 Air, this is the fastest time I get from Rust: > ./bench-threaded-rust.sh Sun Jul 25 07:52:46 CEST 2021 [RUST] threaded_batched.rs (100_000_000) inserts real 0m20.765s user 0m25.916s sys 0m2.303s
- avinassh 5y agoAuthor of the code here and yes, that's correct! Also, it is possible that rust compiler might be optimising this code, remove the random generation calls altogether. (I haven't gotten around to doing the analysis, yet) I am surprised M1 Air taking 20 seconds, on my old machine its 7seconds ish.