Do not use an identity function when no key is given in the unique_everseen recipe

[Numerlor]

The #488 PR simplified the function, but introduced an additional function call that occurred for every element, even when the key function was not supplied by the user.

Changes

The call now occurs only if the key was supplied by the user.

timeit tuple(unique_everseen_opt(range(10_000)))
1.04 ms ± 12.3 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

timeit tuple(unique_everseen_opt(range(1_000_000)))
138 ms ± 442 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)


timeit tuple(unique_everseen(range(10_000)))
1.52 ms ± 39.5 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

timeit tuple(unique_everseen(range(1_000_000)))
185 ms ± 4.95 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

(_opt is the new function)
the runtime difference here is not huge, but the complexity of the code hasn't increased much. The runtime when a key is supplied will also be a tiny bit bigger

[bbayles]

Thanks for the PR. Just for completeness, could you provide a timeit run when using a key?

[Numerlor]

Thanks for the PR. Just for completeness, could you provide a timeit run when using a key?

Sure; as I mentioned the new one is a tiny bit slower because it has to check the condition for every iteration, but it's negligible compared to the speedup gained for when the key is not there

timeit tuple(unique_everseen_opt(range(10_000), key=lambda x: x))
1.53 ms ± 16.2 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

timeit tuple(unique_everseen_opt(range(1_000_000), key=lambda x: x))
186 ms ± 5.77 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

(The original function takes the same time regardless of the key being supplied as it's used unconditionally so nothing changed there.)