cut: fix -s flag for newline delimiter and optimize memory allocation#11143
Conversation
|
GNU testsuite comparison: |
Merging this PR will improve performance by 45.19%
Performance Changes
Comparing Footnotes
|
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
Hi @cakebaker, the tests passed, but the benchmark failed due to an infrastructure issue. Could you please re-run that job? Thanks! |
|
@sylvestre I noticed Attempt №3 was cancelled. Since I don't have permissions to trigger the CI/CD jobs myself, could you let me know if there’s a specific fix I need to make, or if you could re-run the checks when the environment is ready? Thanks! |
|
GNU testsuite comparison: |
|
@cakebaker Switching this to Draft. I've found a performance regression in the hot loop |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
@cakebaker should be ready for a review/merge |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
- Fixed the -s flag incorrectly suppressing output when the delimiter is a newline. - Improved performance in cut_fields_newline_char_delim. - Updated tests to match GNU cut behavior for newline delimiters.
|
GNU testsuite comparison: |
|
Thanks for your PR! |
Fixes & Improvements
-slogic fix: Add the missingonly_delimitedcheck to properly suppress non-delimited lines.split().collect()with amemchr-powered loop. This shifts memory complexity from O(Total File Size) to O(Max Field Size) - as "OOM-safe" as the specification allows.BufReader::consume()to avoid heap copies.segments.get()lookups with a single-passrange_idxpointer that synchronizes "Skip" and "Keep" paths in one linear sweep.Benchmarks
10,000,000 records (
seq 1 10000000 > bench_input.txt), base M1 Pro chip.Case 1: Filtered Selection with Early Exit (
-s -d $'\n' -f 2,1024,4096)gcut./cut_old./cut_newResult: ~224x faster than
cut_old, ~170x faster than GNUcut.Case 2: Full File Read / Base Throughput (
-s -d $'\n' -f 1-10000000)gcut./cut_old./cut_newResult: ~3x faster than
cut_old, ~4x faster than GNUcut.References