perf: Undesired fallback to brute force container uniqueness check on certain input types #893
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.
Hi!
I noticed, that the
uniq
implementation uses_sequence_equal
if the input is sortable. Then, if e.g.[1, 2, 3, 4, 5]
is passed touniq
, then it falls back to brute force because on the first loop iteration_sequence_equal
fails withTypeError: object of type 'int' has no len()
, but it should not as a list of ints is sortable & straightforward to compare.Code sample:
Before: 5.4033913369985385s
After: 0.12076822199924209s
I didn't check whether this was the direct cause of #853, but hopefully, it can improve the status quo :)
Update: The change doesn't affect #853 much (measured by the code sample from the first comment there):
Before: 27.133657693862915 sec
After: 26.14994215965271 sec