join: optimize locale collation performance with hybrid comparison - #10393
join: optimize locale collation performance with hybrid comparison#10393sylvestre wants to merge 1 commit into
Conversation
|
GNU testsuite comparison: |
|
Were you expecting the results of this change to show up here? #10391 |
| } | ||
|
|
||
| // If both are pure ASCII, byte comparison is sufficient for most locales | ||
| if left.is_ascii() && right.is_ascii() { |
There was a problem hiding this comment.
I think this is not a valid assumption:
Heres a one liner that shows that for punctuation byte order does not always equal collation order. Its part of the reason the test was changed in this pr I think
echo -e "ab:d 1\nabc:d 2" | LC_ALL=en_US.UTF-8 join --check-order - <(echo -e "ab:d x\nabc:d y")
yeah, i am confused why it isn't detected |
|
GNU testsuite comparison: |
Performance improvements: - 5.18x faster than upstream locale collation - 35% faster than GNU join for Unicode data - Maintains full locale collation correctness
|
Binary size comparison: |
Merging this PR will degrade performance by 4.76%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | ls_recursive_deep_tree[(200, 2)] |
3.4 ms | 3.7 ms | -6.13% |
| ❌ | Simulation | du_summarize_balanced_tree[(5, 4, 10)] |
15.5 ms | 16 ms | -3.38% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing sylvestre:join-perf (472116d) with main (7cc5cfe)2
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. ↩
-
No successful run was found on
main(bfe212f) during the generation of this report, so 7cc5cfe was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
Performance improvements: