Conversation
Contributor
Author
|
!radar |
|
Benchmark results for b8e10de against 39c26fc are in! @datokrat
Medium changes (1🟥)
Small changes (1✅, 4🟥)
|
b8e10de to
98f06d3
Compare
Collaborator
|
Reference manual CI status:
|
mathlib-nightly-testing bot
pushed a commit
to leanprover-community/batteries
that referenced
this pull request
Feb 9, 2026
mathlib-nightly-testing bot
pushed a commit
to leanprover-community/mathlib4-nightly-testing
that referenced
this pull request
Feb 9, 2026
|
Mathlib CI status (docs):
|
98f06d3 to
a483adf
Compare
8e874ca to
df26bea
Compare
a483adf to
71abf58
Compare
2442a3a to
e9d2e41
Compare
Break down benchmark results by data pattern (reversed, sorted, random, partially sorted) instead of reporting only aggregate time. This reveals that the relative performance of Array.mergeSort vs List.mergeSort depends heavily on data pattern, not element type: | Pattern | List winner? | Ratio | |------------------|--------------|-------------| | Random | no | Array ~2.5x | | Reversed | yes | List ~1.7x | | Sorted | yes | List ~1.8x | | All same | yes | List ~1.6x | | Partially sorted | yes | List ~1.8x | The old aggregate-only benchmark was dominated by the fast low-entropy cases, making List appear faster overall. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Update bench.py and bench2.py to parse the new per-pattern output from the Lean benchmark. bench2.py now generates per-pattern visualizations (2x2 grid + ratio plot). bench.py updated to parse the new aggregate format. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
86be355 to
3be1241
Compare
sgraf812
pushed a commit
that referenced
this pull request
Mar 9, 2026
This PR implements a merge sort algorithm on arrays. It has been measured to be about twice as fast as `List.mergeSort` for large arrays with random elements, but for small or almost sorted ones, the list implementation is faster. Compared to `Array.qsort`, it is stable and has O(n log n) worst-case cost. Note: There is still a lot of potential for optimization. The current implementation allocates O(n log n) arrays, one per recursive call. --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR implements a merge sort algorithm on arrays. It has been measured to be about twice as fast as
List.mergeSortfor large arrays with random elements, but for small or almost sorted ones, the list implementation is faster. Compared toArray.qsort, it is stable and has O(n log n) worst-case cost. Note: There is still a lot of potential for optimization. The current implementation allocates O(n log n) arrays, one per recursive call.