Switch from (crypto-secure) rand to fastrand #12
Conversation
|
@red15 could you test, post the before and after numbers? |
I can't I just cobbled this together on a windows pc and don't have the proper tools to do the timing comparison, I did build and verify with a rust compiler that the code is valid. |
|
no problem at all @red15 :) Let me benchmark it, post the numbers here. |
|
Ok got around to running this as intended:
Not a super big difference but noticeable anyway I'd say ? |
|
Any reason you just ran for busy threads, but not for actual insertions? |
|
I ran this on actual insertions, this reduced 2s further. Thank you! |
Sun Aug 8 13:52:32 IST 2021 [RUST] basic_batched.rs (100_000_000) inserts
real 0m32.424s
user 0m30.826s
sys 0m2.272s
Sun Aug 8 13:53:06 IST 2021 [RUST] threaded_batched.rs (100_000_000) inserts
real 0m30.094s
user 0m42.704s
sys 0m3.877s |
| } | ||
|
|
||
| pub fn get_random_area_code() -> String { | ||
| let mut rng = rand::thread_rng(); | ||
| format!("{:06}", rng.gen_range(0..999999)) | ||
| format!("{:06}", fastrand::u32(0..999_999)) |
There was a problem hiding this comment.
Using perf record ./target/release/busy I found another optimalization that can be done, the Display::Fmt trait is being called quite often for the area code generation, changing it basically to just become
fastrand::u32(100_000..999_999).to_string()saves us from the rather slow Display::Fmt, I can include that change too if you like,
Some numbers of fastrand + display_fmt fix in make busy-rust
real 0m8.211s
user 0m7.208s
sys 0m0.996s
and make busy-rust-thread
real 0m2.605s
user 0m8.691s
sys 0m1.211s
fastrand should be a lot better suited, less hassle with threads trying to optimize random selections.
did not test the threaded build tbh but should be ok.