tail: improve throughput for -c N file

[oech3]

Part of #11607 (non-stream)
The code path without + is different.

$ target/debug/tail -c 1PB /tmp/huge | pv>/dev/null
^C.9GiB 0:00:01 [39.9GiB/s]
$ tail -c 1PB /tmp/huge | pv>/dev/null
^C02GiB 0:00:01 [2.02GiB/s]

[oech3]

$ truncate -s 48k /tmp/page
$ taskset -c 0 hyperfine -N "target/release/tail -c 48k /tmp/page" "target/release/tail-splice -c 48k /tmp/page"
Benchmark 1: target/release/tail -c 48k /tmp/page
  Time (mean ± σ):       1.4 ms ±   0.2 ms    [User: 0.5 ms, System: 0.8 ms]
  Range (min … max):     1.1 ms …   4.0 ms    1836 runs
 
Benchmark 2: target/release/tail-splice -c 48k /tmp/page
  Time (mean ± σ):       1.3 ms ±   0.2 ms    [User: 0.5 ms, System: 0.7 ms]
  Range (min … max):     1.1 ms …   4.6 ms    1660 runs
 
Summary
  target/release/tail-splice -c 48k /tmp/page ran
    1.01 ± 0.25 times faster than target/release/tail -c 48k /tmp/page

Less than the size is very subtle. 32kib sometimes wins and loses.

[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/pr/bounded-memory (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/misc/io-errors is no longer failing!

[codspeed-hq]

Merging this PR will not alter performance

✅ 311 untouched benchmarks
⏩ 46 skipped benchmarks¹

---

_{Comparing oech3:tail-non-plus (c14925f) with main (964610c)}

Footnotes

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

[xtqqczze]

1.01 ± 0.25 times faster than target/release/tail -c 48k /tmp/page

It's not statistically significant?

[sylvestre]

is it interesting ? :)

[oech3]

Someone might try to truncate header part from large iso file to extract a small file.

[xtqqczze]

std::io::copy is already optimized to use splice(2) syscalls on Linux. If there’s a measurable performance gap here, it would likely be better addressed upstream in Rust’s standard library.

[oech3]

`io::copy` is slower than manually calling it. I'm not 100% sure, but maybe pipe size is not 1 MiB. Also there is some cases that `io::copy` breaks some tests checking buffering behavior.

[oech3]

More importantly, io::copy breaks some FUSE filesystem's stat. But upstream is clearly not interested to fix it. So relying on io::copy is really bad idea.

[xtqqczze]

More importantly, io::copy breaks some FUSE filesystem's stat. But upstream is clearly not interested to fix it. So relying on io::copy is really bad idea.

@oech3 The PR description and comments should clearly state the motivation for this change. It was not apparent that this was intended to address a correctness issue with FUSE.

[oech3]

This PR's main target is perf only to avoid large diff. Nothing is wrong. I'll provide a different PR for FUSE.

[oech3]

If I am understanding correctly, we were not extending pipe size to 1 MiB at #6964 (comment) . But splice call was faster than io::copy at there already.

[oech3]

and rustix::pipe::fcntl_setpipe_size does not affect to io::copy :|

[sylvestre]

LGTM — nice throughput improvement using zero-copy splice for the bounded -c N path.