mktemp: Use fastrand for perf

[oech3]

1225848 -> 1215816 byte.

$ taskset -c 1 hyperfine -N --warmup 20 'mktemp -u' 'mktemp-fast -u'
... 
Summary
  mktemp-fast -u ran
    1.06 ± 0.13 times faster than mktemp -u

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/inotify-dir-recreate (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/tty/tty-eof (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/csplit/csplit-heap is now passing!
Congrats! The gnu test tests/printf/printf-surprise is now passing!
Congrats! The gnu test tests/tail/pipe-f is now passing!
Congrats! The gnu test tests/tail/tail-n0f is now passing!

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/pr/bounded-memory (fails in this run but passes in the 'main' branch)
Congrats! The gnu test tests/misc/io-errors is no longer failing!
Congrats! The gnu test tests/tail/tail-n0f is now passing!

[codspeed-hq]

Merging this PR will not alter performance

✅ 294 untouched benchmarks
⏩ 42 skipped benchmarks¹

---

_{Comparing oech3:fastrand (a0aec0c) with main (12b284c)²}

Footnotes

1. 42 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (8537062) during the generation of this report, so 12b284c was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[sylvestre]

not sure it is worse the added complexity and extra dep for a small win for a program that doesn't required much performance, no ?

[oech3]

mktemp can be called from script many times.

We can remove ring from dep instead to reduce deps.

[oech3]

I'll do one of

• close sort: Use fastrand #11125 and this PR
• undraft sort: Use fastrand #11125 after this was merged

[xtqqczze]

An 8,512-byte reduction in binary size is a nice win.

That said, this switches the RNG from ChaCha to wyrand, which is not cryptographically secure. I’m not sure that’s a problem in this context, but it’s worth calling out explicitly so we’re clear about the trade-off.

[sylvestre]

8.5k = 0.69% reduction, i am not convinced :)

[oech3]

This PR still use "getrandom" as seed.

[xtqqczze]

What do results look like with nanorand::ChaCha?

[oech3]

cannot compile it.

[xtqqczze]

nanorand::WyRand has a 64 bit output size, which only provides enough entropy for 10 X's?

[xtqqczze]

cannot compile it.

you need to add the chacha feature to nanorand in Cargo.toml then use nanorand::ChaCha12

[xtqqczze]

I think for this PR, you can use fastrand::Rng in dry_exec (which uses WyRand), since the wet run already uses it as a dependency of the tempfile crate.

We can open an issue regarding the non-cryptographically secure RNG.

[oech3]

No. fastrand does not support writing to buf at once, and was actually slower than nanorand. 1215816 byte, similar perf.

[sylvestre]

If I may, I think you are over iterating on this :)

[oech3]

since the wet run already uses it as a dependency of the tempfile

So does it reduce build time?

[xtqqczze]

So does it reduce build time?

It's one less dependency, so that's a win

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/cut/bounded-memory (fails in this run but passes in the 'main' branch)
Congrats! The gnu test tests/misc/io-errors is no longer failing!
Note: The gnu test tests/rm/many-dir-entries-vs-OOM is now being skipped but was previously passing.

[oech3]

Does tempfile have any option to use secure-rng? We could reduce dep without introducing new rng.

[xtqqczze]

No, see Stebalien/tempfile#178.

[Stebalien]

Tempfile uses getrand to re-seed fastrand if it keeps failing to create temporary files. However, it doesn't currently have an option to use ONLY getrand.

[oech3]

Should we remove mktemp dep if we already have a function to generate file name?

[xtqqczze]

Should we remove mktemp dep if we already have a function to generate file name?

Which dependency do you propose removing?

[oech3]

One of rng or mktemp easier to remove.

[oech3]

I'll make 1 PR if you don't want to have 3 PRs for dropping 1 (translative) dep.