true, false: Improve perf & fix clippy::unnecessary_wraps

[oech3]

Closes #11177

[codspeed-hq]

Merging this PR will improve performance by ×39

⚡ 2 improved benchmarks
✅ 302 untouched benchmarks
⏩ 42 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	false_consecutive_calls	6,624.4 ns	170.3 ns	×39
⚡	Simulation	true_consecutive_calls	6,428.6 ns	170.3 ns	×38

---

_{Comparing oech3:true-clippy (869ffea) with main (1f7c81f)}

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. ↩

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/pr/bounded-memory (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tty/tty-eof (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/cut/bounded-memory is now being skipped but was previously passing.
Congrats! The gnu test tests/seq/seq-epipe 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)
Congrats! The gnu test tests/cut/bounded-memory is now passing!
Congrats! The gnu test tests/dd/no-allocate is now passing!

[oech3]

I considered that --help needs SIGPIPE handling, but ... | head -n 1 did not panic.

[sylvestre]

this is fascinating

[oech3]

Still 2x slower than GNU. Needs help of Rust std itself to win.

[xtqqczze]

In most shells, true and false are implemented as built-in commands, so this is not worth optimising further.

[oech3]

We cannot symlink shell built-ins as dummy and cannot call from other binaries.
Also slow true is one of a barrier to make all of Ubuntu's coreutils uu.

[xtqqczze]

I mean we don't need to focus on optimising further, since modern shells won't be using our implementations.

Besides, 1.7 ns per call is already fast in absolute terms.

[oech3]

OK. I'll consider the reasonable way to extend this idea for other utils before optimizing true.

[xtqqczze]

I wonder why we only saw improvements for consecutive calls benchmarks and not for false_no_args and true_no_args.

[oech3]

true_no_args
src/uu/true/benches/true_bench.rs
N/A
813.3 ns
< 1 ns

[xtqqczze]

< 1ns makes doesn't make sense. For comparison, that is less than 5 cycles on a 5 GHz CPU

[oech3]

I meant 813.3 ns to less than 1ns

[xtqqczze]

Less than 1 ns doesn't seem plausible, I'm suggesting there is some kind of measurement error.

[oech3]

The bench does not inclode time for process generation.