tr: use POSIX_FADV_SEQUENTIAL#13506
Conversation
|
It is useful for file input. Not for stdin (which is stream at most cases). |
|
|
||
| let trace_file = at.plus_as_string("strace.out"); | ||
| let result = Command::new("strace") | ||
| .args(["-o", &trace_file, "-e", "fadvise64,fadvise64_64"]) |
There was a problem hiding this comment.
The test does not check that fadvise is properly called for file's fd.
|
OK. My issue is invalid at here:( . I misunderstood that |
|
GNU testsuite comparison: |
Merging this PR will improve performance by 3.43%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ⚡ | Simulation | ls_recursive_balanced_tree[(6, 4, 15)] |
51.2 ms | 49.4 ms | +3.57% |
| ⚡ | Simulation | du_all_wide_tree[(5000, 500)] |
16.8 ms | 16.2 ms | +3.57% |
| ⚡ | Simulation | du_max_depth_balanced_tree[(6, 4, 10)] |
26.1 ms | 25.3 ms | +3.14% |
Tip
Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.
Comparing wtcpython:tr-sequential-fadvise (ce062e0) with main (be96f5d)
Footnotes
-
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. ↩
|
@oech3 is that ok with you ? |
|
This is useful for the case |
Fixes #13121.
trreads standard input sequentially but did not provide the kernel with a corresponding access-pattern hint.Call
fadvisewithPOSIX_FADV_SEQUENTIALon standard input on supported platforms, treating it as a best-effort optimization so failures do not change command behavior. Add a Linuxstraceregression test that verifies the advice is issued.