tee: increase buf size for large input

[oech3]

taskset -c 1 yes|taskset -c 2 target/release/tee|taskset -c 3 pv>/dev/null

This PR: [3.83GiB/s]
gnu58d88d243/tee: [2.83GiB/s]
closes #11432

[xtqqczze]

The existing code is documented to use same DEFAULT_BUF_SIZE as Rust std library for the stack allocated array.

[xtqqczze]

GNU coreutils uses IO_BUFSIZE = 256 * 1024, we have overhead from zero-initialization though.

[oech3]

Optimal value might different at each PC. 64*1024 was best for me.

[xtqqczze]

taskset -c 1 yes|taskset -c 2 target/release/tee|taskset -c 3 pv>/dev/null

This measures throughput in the most ideal scenario for a large buffer, we should ensure performance does not regress in other cases where output is small.

[oech3]

Time for small input is bounded. But I could use smaller buf only for 1st cycle.

[xtqqczze]

Please test something like: taskset -c 1 yes | head -c 8192 | taskset -c 2 target/release/tee|taskset -c 3 pv>/dev/null

[oech3]

I added a code path for smaller input. There is variance at
taskset -c 1 hyperfine --runs 100 -N --warmup 10 -- "target/release/tee8 <in" "target/release/tee64 <in" "target/release/tee8and64 <in",

Both of win and lose happen at tee8and64 vs tee8, but tee64 never win.

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/date/resolution (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tail/symlink (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/rm/many-dir-entries-vs-OOM 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/tail/symlink (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tail/follow-name (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/tail/pipe-f2 is no longer failing!
Note: The gnu test tests/cut/bounded-memory is now being skipped but was previously passing.
Note: The gnu test tests/expand/bounded-memory is now being skipped but was previously passing.

[sylvestre]

needs to be rebased

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/cut/bounded-memory (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/tail/tail-n0f is now being skipped but was previously passing.

[github-actions]

GNU testsuite comparison:

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)

[xtqqczze]

I added a code path for smaller input.

@oech3 Could you quantify the performance improvement from the additional code path to justify the added complexity?

[oech3]

This PR was opened for larger files. Mostly 0 perf change for small files.

[sylvestre]

Please add a benchmark in a different PR
Once it is landed, we will retrigger this one to evaluate the performance impact
thanks

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/cut/bounded-memory (passes in this run but fails 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/pr/bounded-memory (passes in this run but fails in the 'main' branch)

[oech3]

Is it equivalint with

truncate -s SIZE b
time tee < b >/dev/null

?

[oech3]

How to use stdin at benchmark?