On Thu, Oct 14, 2021 at 11:15:52PM +1100, Chris Angelico wrote:
On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
wrote: Results are in (tested `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their `next(reverse())` counterparts): `*` / `/` implemented is 2x faster than `next(iter(d))`/`next(reversed(d))` `+` / `-` implemented is approximately 3x faster than `next(iter(d.values()))`/`next(reversed(d.values()))` `<<` / `>>` implemented is at least 4x faster than `next(iter(d.items()))`/`next(reversed(d.items()))`
So, negligible benefits. Thanks for checking.
Be fair Chris :-) A 2x or 4x speed-up (even of a micro-benchmark) is not negligible. If someone managed a mere 20% or 30% speedup to next(), we would probably be more than happy to take it. A better way to put this is that while the speed benefit to one uncommon task is non-negligible, the cost to readability and comprehensibility is horrendous. This is premature optimization: there's no evidence that getting the first element of a dict is a common operation, let alone a bottleneck that needs optimising. Ultimately, for every millisecond in program runtime saved by using obscure operators for uncommon operations on dicts, we would probably cost a dozen programmers five or ten minutes in confusion while they try to decipher what on earth `mydict << 1` means. There are programming languages designed to be terse and even deliberately obfuscated, especially code-golfing languages. I'm glad Python is not one of them :-) -- Steve