factor:performance tuning

[mattsu2020]

Performance improvement for large numbers

fix this issue https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2131212

[github-actions[bot]]

GNU testsuite comparison:

Skip an intermittent issue tests/misc/tee (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tail/overlay-headers (fails in this run but passes in the 'main' branch)

[github-actions[bot]]

GNU testsuite comparison:

Skipping an intermittent issue tests/tail/overlay-headers (passes in this run but fails in the 'main' branch)

[github-actions[bot]]

GNU testsuite comparison:

Skipping an intermittent issue tests/tail/overlay-headers (passes in this run but fails in the 'main' branch)

[sylvestre]

could you please run hyperfine with the three programs? gnu, without the patch and with the patch and share the full results here? thanks :)

[github-actions[bot]]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/overlay-headers (fails in this run but passes in the 'main' branch)

[mattsu2020]

could you please run hyperfine with the three programs? gnu, without the patch and with the patch and share the full results here? thanks :)

Implementation Details

GMP 6.3.0 and GNU coreutils 9.5 were built and installed from source

Created factor_numbers_u128_repeat.txt (60 lines) as benchmark input, containing 6 composite numbers ranging from 64 to 128 bits repeated 10 times. Confirmed factorization completion across all 3 implementations and reran Hyperfine. All commands used the release profile (target/profiling/factor). Hyperfine execution results Command: hyperfine --warmup 3 --runs 12 “ < factor_numbers_u128_repeat.txt”

Implementation	Average time (s)	Standard deviation (s)	Minimum–Maximum (s)
GNU coreutils 9.5 ( local-gnu/bin/factor)	6.718	0.106	6.594 – 7.020
Old implementation (prev_worktree/target/profiling/factor)	6.125	1.942	2.648 – 8.508
After patch application (target/profiling/factor)	6.993	1.585	4.299 – 9.457

To reduce variance, we adjusted to 3 warm-ups + 12 measurements, but the Rust version still shows relatively high dispersion due to its randomized algorithm. For greater stability, consider running at times of low system load or using CPU pinning. Behavior with inputs exceeding 128 bits

For factor_numbers.txt (max ~260 bits), both the GNU version and the patched version achieved complete factorization. The old implementation returned factor: Factorization incomplete. Remainders exist. and exited with exit code 1. This confirms the improvement in support for large integers. factor_numbers_u128_repeat.txt

[codspeed-hq[bot]]

CodSpeed Performance Report

Merging #9261 will not alter performance

_{Comparing mattsu2020:factor_fix (4befbdd) with main (3108c45)}

Summary

✅ 127 untouched
⏩ 6 skipped[^skipped]

[^skipped]: 6 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[bot]]

GNU testsuite comparison:

Skipping an intermittent issue tests/tail/overlay-headers (passes in this run but fails in the 'main' branch)

[github-actions[bot]]

GNU testsuite comparison:

Skipping an intermittent issue tests/misc/tee (passes in this run but fails in the 'main' branch)

[github-actions[bot]]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/overlay-headers (fails in this run but passes in the 'main' branch)

[sylvestre]

Any idea why codspeed does not detect it?

[mattsu2020]

Any idea why codspeed does not detect it?

If I were to consider it, I would create test cases with large integers.

[github-actions[bot]]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/overlay-headers (fails in this run but passes in the 'main' branch)

[github-actions[bot]]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/overlay-headers (fails in this run but passes in the 'main' branch)